Method and device for processing graph query request based on multi-stage intermediate representation

Abstract

The embodiment of the invention provides a method and device for processing a graph query request based on multi-stage intermediate representation. The method comprises the steps that the graph query request written by utilizing a graph query language is converted into AST; according to a target dialect set for a graph query language, the AST is converted into a dialect IR through a first infrastructure provided by an MMIR frame, and the MMIR frame further provides a Pass manager; and optimizing the dialect IR by using a target Pass pipeline configured by the Pass manager, and converting the optimized dialect IR into a physical execution plan which can be executed by a graph query engine of the graph database.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computers, and more particularly to a method and apparatus for processing graph query requests based on multi-level intermediate representation (MLIR). Background Technology

[0002] Graph databases, capable of handling complex relational data, are widely used in numerous technological scenarios such as social networks, financial risk control, the Internet of Things, knowledge graphs, and recommendation systems. Graph query requests, used to retrieve data from a graph database, are typically written in various standards-compliant graph query languages. These requests usually need to be parsed into a logical plan, optimized, and then transformed into a physical execution plan that can be executed by the graph database's graph query engine.

[0003] In related technologies, the acquisition and optimization of logical plans are usually performed by isolated and closed computer program modules, resulting in poor system performance and scalability, and difficulty in coping with frequent updates to optimization strategies and extended graph operations. Summary of the Invention

[0004] This specification provides a method and apparatus for processing graph query requests based on MLIR in one or more embodiments.

[0005] In a first aspect, a method for processing graph query requests based on MLIR is provided. The method includes: converting a graph query request written using a graph query language into an Abstract Syntax Tree (AST); converting the AST into a dialect intermediate representation (IR) using a first infrastructure provided by the MLIR framework, based on a target dialect set for the graph query language, wherein the MLIR framework also provides a Pass Manager; optimizing the dialect IR using a target Pass pipeline configured through the Pass Manager, and converting the optimized dialect IR into a physical execution plan that can be executed by the graph query engine of the graph database.

[0006] Secondly, an apparatus for processing graph query requests based on MLIR is provided. The apparatus includes: a parsing processing unit for converting a graph query request written in a graph query language into an AST; a conversion processing unit for converting the AST into a dialect IR based on a target dialect set for the graph query language and using a first infrastructure provided by the MLIR framework, wherein the MLIR framework also provides a Pass manager; and an optimization processing unit for optimizing the dialect IR using a target Pass pipeline configured through the Pass manager, and converting the optimized dialect IR into a physical execution plan that can be executed by the graph query engine of a graph database.

[0007] Thirdly, a computer-readable storage medium is provided having a computer program / instructions stored thereon, wherein when the computer program / instructions are executed in a computing device, the computing device performs the method as described in the first aspect.

[0008] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores a computer program / instruction, and the processor executes the computer program / instruction to implement the method as described in the first aspect.

[0009] The methods and apparatus provided in one or more embodiments of this specification, by pre-setting a target dialect for the graph query language, utilizing certain infrastructure provided by the MLIR framework to assist in converting the AST of a graph query request into the corresponding dialect IR, and using the Pass Manager provided by the MLIR framework to configure the target Pass pipeline, and using the Pass sequence in the target Pass pipeline to optimize the dialect IR, achieve deep integration of the compilation and optimization process of the graph query request, which is conducive to more efficient conversion of graph query requests into physical execution plans. Simultaneously, developers can directly update the target dialect to extend graph operations on the graph query language, and flexibly configure the Pass sequence in the Pass pipeline used to optimize the dialect IR through the Pass Manager to update the optimization strategy, providing better flexibility and scalability. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments in this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a method for processing graph query requests based on MLIR, as provided in the embodiments of this specification.

[0012] Figure 2 This is a schematic diagram of a Pass pipeline configured for a graph query request, as provided in the embodiments of this specification.

[0013] Figure 3 This is a schematic diagram of an apparatus for processing graph query requests based on MLIR provided in the embodiments of this specification. Detailed Implementation

[0014] The various non-limiting embodiments provided in this specification will now be described in detail with reference to the accompanying drawings.

[0015] The MLIR framework (also known as MLIR for short) is an open-source compiler infrastructure that supports multi-level Interpreter Representation (IR) and enables cross-level program transformations. MLIR allows the integration of one or more dialects (Dialects) within the same framework. These Dialects include MLIR's built-in Dialects and developer-defined Dialects. A Dialect is a collection of operations, types, and attributes used to describe semantics at a specific domain or level of abstraction. MLIR also provides a general pass management mechanism, a type system, and optimization tools, suitable for compiling and optimizing programs in complex domains. In specific technical scenarios, MLIR is often provided as a statically linked library or a dynamically linked library.

[0016] This specification provides at least one method, apparatus, computer-readable storage medium, and computing device for processing graph query requests based on MLIR. By pre-setting a target dialect for the graph query language, utilizing certain infrastructure provided by the MLIR framework to assist in converting the AST of the graph query request into the corresponding dialect IR, and using the Pass Manager provided by the MLIR framework to configure the target Pass pipeline, and using the Pass sequences in the target Pass pipeline to optimize the dialect IR, the compilation and optimization processes of the graph query request are deeply integrated, facilitating a more efficient conversion of the graph query request into a physical execution plan. Simultaneously, developers can directly update the target dialect corresponding to the graph query request to extend graph operations on the graph query language, and flexibly configure the Pass sequences in the Pass pipeline used to optimize the dialect IR through the Pass Manager to update the optimization strategy, providing better flexibility and scalability.

[0017] Figure 1 This is a flowchart illustrating a method for processing graph query requests based on MLIR, as provided in the embodiments of this specification. This method can be executed by any device, platform, equipment, or cluster of devices with computing / processing capabilities.

[0018] Reference Figure 1 As shown, the method may include, but is not limited to, some or all of the following steps S101 to S109.

[0019] Step S101: Convert the graph query request written using the graph query language into an AST.

[0020] Graph query languages ​​can be GQL (Graph Query Language), a standard query language developed by the International Organization for Standardization (ISO / IEC) for property graph data models. It supports declarative operations on nodes, edges, properties, and paths, and its core functions include pattern matching, WHERE clauses, projection, aggregation, and updates. Alternatively, it can be other graph query languages ​​besides GQL, such as Cypher, Gremlin, SPARQL, and PGQL.

[0021] First, the graph query request can be parsed into a series of tokens by performing lexical analysis. Then, the series of tokens can be constructed into an AST according to the corresponding grammar rules. The AST is a tree-structured data, and each node in the AST represents a language structure (such as node pattern, edge pattern, attribute condition, etc.).

[0022] Step S103: Determine the current query type of the graph query request.

[0023] Graph query requests can be categorized into Online Transaction Processing (QLTP) and Online Analytical Processing (OLAP). OLTP typically involves a large number of short-duration, high-concurrency read / write operations, such as inserts, updates, deletes, and simple queries. These operations usually target single or small numbers of records, emphasizing fast response and transaction integrity. OLAP, on the other hand, typically involves aggregation, grouping, and join operations on large datasets. These operations are often read-only and used for report generation and data analysis, with potentially longer response times.

[0024] For example, refer to the following example of graph query requests Q1 and Q2 written using the graph query language GQL:

[0025] Q1,MATCH(n:Entity{id:1})RETURN n.id;

[0026] Q2, MATCH(n:Entity{id:1})-[e:Rel]->(m:Entity)RETURNe.src_id as SRCID, e.dst_id as DSTID, e LIMIT 100THEN RETURN DSTID, COUNT(DSTID) as cnt GROUP BYDSTID.

[0027] The graph query request Q1 in the previous example is a simple point query and does not involve aggregation, join, or other complex computational operations. The query type of graph query request Q1 is OLTP. The graph query request Q2 in the previous example involves more complex computational operations such as COUNT and GROUP BY. The query type of graph query request Q2 is OLAP.

[0028] Step S105: Configure the target Pass pipeline using the Pass Manager of the MLIR framework, based on the current query type.

[0029] The MLIR framework provides a large number of built-in passes, which may include, but are not limited to, passes for normalizing IR (canonicalizer), passes for dead code elimination (DCE) of IR (referred to as DCE in this paper), and passes for common sub-expression elimination (CSE) of IR (referred to as CSE in this paper).

[0030] The MLIR framework also provides a wealth of infrastructure to support developers in customizing Passes. This infrastructure may include, but is not limited to, a Def-Use chain analysis tool, a Pass base class for defining Passes, a Pattern Rewriter base class for rewriting IRs, and a Rewrite Pattern base class for defining IR rewriting rules, and so on.

[0031] Developers can use this infrastructure as needed to construct custom passes, which can be used to optimize IR and convert the optimized IR into corresponding physical execution plans. For example, by inheriting the Pass base class, Pattern Rewriter base class, and Rewrite Pattern base class, and overriding the virtual functions in the base classes, and calling the Def-Use chain analysis tools (specifically, the numerous application programming interfaces provided by MLIR) as needed within these virtual functions, at least one custom pass can be implemented to perform at least one optimization operation on the dialect IR described herein. Furthermore, custom passes can be defined to convert the optimized dialect IR into physical execution plans. The at least one optimization operation in the aforementioned example may include, but is not limited to, one or more of the following optimization operations: predicate pushdown, full table scan replaced with primary key lookup, column pruning, path pattern optimization, aggregation optimization (such as aggregation before joining to reduce data volume), join optimization (such as adjusting the join order based on execution cost), data partitioning (partition pruning based on query conditions), and vectorization optimization. These optimization operations can be implemented, for example, through custom passes such as Pass21 to Pass28.

[0032] The following is an explanatory description of some of the optimization operations in the aforementioned examples.

[0033] Graph query requests may involve multi-stage queries, where the results of a previous query stage may not be used in subsequent stages. For example, in the graph query request Q2 mentioned earlier, the return value 'e' is returned in the RETURN of the first query stage; however, in the RETURN of the second query stage, only the DSTID is used, while the SRCID and 'e' are not referenced. Dead code elimination can remove the SRCID and 'e' from the RETURN of the first query stage, reducing data processing volume.

[0034] A single node may include multiple attributes, and the attributes of the nodes to be returned in a graph query request may only include a subset of the attributes of nodes that meet the query criteria. By using the Def-Use chain analysis tool provided by MLIR to define a Pass (e.g., Pass23) for column pruning in the IR, Pass23 can identify which fields / attributes in the dialect IR of the graph query request are not used in subsequent calculations. This allows for optimization by retrieving only the attribute values ​​of the necessary attributes, thus improving query performance.

[0035] Graph query requests may involve path queries containing multiple nodes and one or more edges. In unoptimized dialect IR, there may be instances of repeated visits to the same nodes and edges. Path pattern optimization allows for the flexible construction of operators for conditional filtering, supporting SIMPLE (the path can have the same start and end nodes, but no other nodes are the same), ASYCLIC (the path has no duplicate nodes), and TRAIL (the path has no duplicate edges).

[0036] Developers can also define a custom target pass for converting the optimized IR into a physical execution plan. This target pass will be added to the target pass pipeline as the last pass in the sequence of passes included in the target pass pipeline. Alternatively, developers can write their own separate computer program component for converting the optimized IR into a physical execution plan.

[0037] Developers can select the built-in Passes provided by the MLIR framework as needed and add them to the target Pass pipeline through the Pass Manager provided by MLIR; correspondingly, developers can also select custom Passes that utilize the infrastructure provided by MLIR as needed and add them to the target Pass pipeline through the Pass Manager provided by MLIR.

[0038] As mentioned earlier, graph query requests of type OLTP typically involve a large number of short-duration, high-concurrency read and write operations, such as inserts, updates, deletes, and simple queries. These operations usually target a single or small number of records, emphasizing fast response and transaction integrity. Graph query requests of type OLAP typically involve aggregation, grouping, and join operations on large datasets. These operations are often read-only and used for report generation and data analysis, and their response time may be relatively long. To improve the processing efficiency of query requests, different target pass pipelines can be configured for OLTP and OLAP.

[0039] Reference Figure 2 As shown, Pass pipeline PP1 is configured for OLTP query type, and Pass pipeline PP2 is configured for OLAP query type. PP1 and PP2 include different Pass sequences. For example, the Pass sequence included in PP1 is Canonicalizer for normalizing IR, DCE for dead code elimination of IR, Pass-21 for predicate pushdown of IR, Pass-22 for full table scan replacement of primary key lookup of IR, and Pass-23 for column pruning of IR; the sequence included in PP2 is Canonicalizer, DCE, CSE, and Pass21 to Pass28.

[0040] The Pass pipeline used for IR optimization comprises a sequence of Passes, with different optimization operations implemented through different Passes. Developers can independently develop different Passes for different optimization operations. When a user needs to update the optimization strategy, this may involve updating the operation strategy of a single optimization operation, adding a new optimization operation, or discontinuing an existing optimization operation. When updating the specific operation strategy of an optimization operation, the relevant Passes in the Pass pipeline can be updated independently without affecting the Passes used to implement other optimization operations. When adding a new optimization operation, a Pass for implementing that optimization operation can be independently developed and added to the Pass pipeline. When discontinuing an existing optimization operation, the Pass used to implement that optimization operation can be removed from the Pass pipeline.

[0041] It should be noted that the aforementioned steps S103 and S105 are optional. Alternatively, the query type of the graph query request may not be identified, and the same target Pass pipeline may be directly configured for OLTP and OLAP through the Pass Manager.

[0042] Step S107: Based on the target dialect set for the graph query language, the AST is converted into a dialect IR using the first infrastructure provided by the MLIR framework.

[0043] The target dialect is specifically designed for graph query languages. Like regular dialects, it is also a set of operations, types, and attributes. The difference is that the operations in the target dialect are graph operations that can be adapted to graph query languages. These graph operations can be used to express the access patterns of graph data, and may include, but are not limited to, graph operations such as Node Primary Lookup, Path Match, and Guard Equal.

[0044] The aforementioned first infrastructure includes at least one of the following infrastructures: a dialect registration interface, an operation construction interface, a type system interface, and an attribute system interface for registering dialects. For example, the dialect registration interface can be called first to register the target dialect in the MLIR context. Then, based on the conversion rules of the target graph query language defined in the conversion processing unit developed by the developer, the operation construction interface, type system interface, and attribute system interface, etc., can be called as needed to convert the graph query request into the corresponding dialect IR according to the registered target dialect.

[0045] For example, the AST of the graph query request Q1 in the aforementioned example can be converted into a dialect IR as shown in the following example:

[0046] / / MATCH(n:Entity{id:1})RETURN The dialect IR of n.id, the name of the target dialect is gu.graph / /

[0047] module{

[0048] / / Define the main function, which takes a graph parameter of type ! gu.graph<1:i32>

[0049] func.func@main(%arg0:!gu.graph<1:i32>){

[0050] / / Operation 1: Match all nodes in the graph and return a graph (the set of matched nodes) / /

[0051] %0="gu.match_from_graph"(%arg0):(!gu.graph<1:i32>)->! gu.graph<1:i32>

[0052] / / Operation 2: Access the graph returned by Operation 1, extract the node labels and the attribute values ​​of all 20 attributes. The 20 attributes specifically include id, entity_type, deleted, gen_time, name, guid, status, props, test1,...test12 / /

[0053] %label,%props:20="gu.visit_node"(%0)<{node_schema=! gu <node_schema 1:i32"Entity"[0]indexes[][1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20]["id","entity_type","deleted","gen_time","name","guid","status","props","test1","test2","test3","test4","test5","test6","test7","test8","test9","test10","test11","test12"][i64,!gu.string,i64,i64,!gu.string,!gu.string,i64,!gu.string,i64,i64,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string]>}>:(!gu.graph<1:i32>)->(!gu.label<"Entity">,i64,!gu.string,i64,i64,!gu.string,!gu.string,i64,!gu.string,i64,i64 ,!gu.string,!gu.string,!gu.string,!

[0054] / / Operation 3: Package the attribute values ​​of all 20 attributes returned by Operation 2 into a single entity object / /

[0055] %1="gu.pack_entity"(%props#0,%props#1,%props#2,%props#3,%props#4,%props#5,%props#6,%props#7,%props#8,%props#9,%props#10,%props#11,%props#12,%props#13,%props#14,%props#15,%props#16,%props#17,%props#18,%props#19):(i64,!gu.string,i64,i64,!gu.string,!gu.string,i64,!gu.string,i64,i64,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string)->!gu.entity<true,!gu.label<"Entity">,!gu<node_schema 1:i32"Entity"[0]indexes[][1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20]["id","entity_type","deleted","gen_time","name","guid","status","props","test1","test2","test3","test4","test5","test6","test7","test8","test9","test10","test11","test12"][i64,!gu.string,i64,i64,!gu.string,!gu.string,i64,!gu.string,i64,i64,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string,!gu.string]>,["id","entity_type","deleted","gen_time","name","guid","status","props","test1","test2","test3","test4","test5","test6","test7","test8","test9","test10","test11","test12"],[i64,! gu.string,i64,i64,! gu.string,! gu.string,i64,! gu.string,i64,i64,! gu.string,! gu.string,! gu.string,! gu.string,! gu.string,! gu.string,! gu.string,! gu.string,! gu.string,! gu.string]>.

[0056] / / Operation 4: Create a constant with a value of 1 and a type of i64 / /

[0057] %2="gu.constant"()<{value=1:i64}>:()->i64

[0058] / / Operation 5: Check if the value of attribute 0, i.e., id, is equal to the constant 1. If yes, throw an error or terminate; otherwise, continue. / /

[0059] "gu.guard_eq"(%props#0,%2):(i64,i64)->()

[0060] / / Operation 6: Return attribute 0, i.e., id, as the result, listed as "n.id" / /

[0061] "gu.return_with_column"(%props#0)<{columnNames=["n.id"]}>:(i64)->()

[0062] }

[0063] }

[0064] Step S109: Optimize the dialect IR using the target Pass pipeline, and convert the optimized dialect IR into a physical execution plan that can be executed by the graph query engine of the graph database.

[0065] Please continue to refer to Figure 2As shown, when the query type of the graph query request is OLTP, such as the graph query request Q1 in the previous example, the dialect IR can be optimized by optimizing the target Pass pipeline PP1 configured for OLTP and converting the optimized dialect IR into a physical execution plan; when the query type of the graph query request is OLAP, such as the graph query request Q2 in the previous example, the dialect IR can be optimized by optimizing the target Pass pipeline PP1 configured for OLAP and converting the optimized dialect IR into a physical execution plan.

[0066] Following the previous example, the dialect IR for graph query request Q1 can be optimized through the target pass pipeline as follows:

[0067] / / MATCH(n:Entity{id:1})RETURN n.id's dialect IR optimized through the target Pass pipeline / /

[0068] module{

[0069] / / Define the main function / /

[0070] func.func@main(%arg0:!gu.graph<1:i32>){

[0071] / / Operation 1: Create constant value 1 / /

[0072] %0="gu.constant"()<{value=1:i64}>:()->i64

[0073] / / Operation 2: Find the node by primary key, that is, find the node whose attribute id value is 1. / /

[0074] %label,%props=gu.node_primary_lookup(%arg0,%0)<{node_type_id=1:i32, retained_columns=array <i32:1>}>:(!gu.graph<1:i32>,i64)->(!gu.label<"Entity">,i64)

[0075] / / Return the search results of operation 2

[0076] "gu.return_with_column"(%props)<{columnNames=["n.id"]}>:(i64)->()

[0077] }

[0078] }

[0079] The conversion of the optimized dialect IR into a physical execution plan suitable for the graph query engine depends on the specific operations and data types that the graph query engine can recognize and process. For example, it may be a sequence or set of operations in JSON format that can be recognized and executed by the graph query engine. No restrictions are placed on the conversion process here.

[0080] Based on the same concept as the foregoing method embodiments, this specification also provides an apparatus 300 for processing graph query requests based on MLIR. (Refer to...) Figure 3 As shown, the apparatus 300 includes: a parsing processing unit 301, used to convert a graph query request written using a graph query language into an AST; a conversion processing unit 303, used to convert the AST into a dialect IR using a first infrastructure provided by an MLIR framework, based on a target dialect set for the graph query language, wherein the MLIR framework also provides a Pass manager; and an optimization processing unit 305, used to optimize the dialect IR using a target Pass pipeline configured through the Pass manager, and convert the optimized dialect IR into a physical execution plan method that can be executed by the graph query engine of the graph database.

[0081] Those skilled in the art will recognize that, in one or more of the examples above, the functions described herein can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, the computer program corresponding to these functions can be stored in a computer-readable medium or transmitted as one or more instructions / code on a computer-readable medium so that when the computer program corresponding to these functions is executed by a computer, the methods described in any embodiment of this specification can be implemented by the computer.

[0082] This specification also provides a computer-readable storage medium storing a computer program, which, when executed in a computing device, enables the computing device to execute a method for processing graph query requests based on MLIR provided in any embodiment of this specification.

[0083] This specification also provides a computing device in its embodiments, including a memory and a processor. The memory stores executable code, and when the processor executes the executable code, it implements a method for processing graph query requests based on MLIR provided in any embodiment of this specification.

[0084] The various embodiments in this specification are described in a progressive manner. Similar or identical parts in each embodiment can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0085] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0086] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for processing graph query requests based on multi-level intermediate representations, the method comprising: Transform graph query requests written using a graph query language into an abstract syntax tree (AST); Based on the target dialect set for the graph query language, the AST is converted into a dialect intermediate representation IR using the first infrastructure provided by the multi-level intermediate representation (MLIR) framework, which also provides a Pass manager. The dialect IR is optimized using the target Pass pipeline configured through the Pass manager, and the optimized dialect IR is converted into a physical execution plan that can be executed by the graph query engine of the graph database.

2. The method according to claim 1, wherein the target Pass pipeline includes a first Pass provided by the MLIR framework, the first Pass being used to normalize the dialect IR; and / or, the target Pass pipeline includes a second Pass provided by the MLIR framework, the second Pass being used to eliminate dead codes in the dialect IR.

3. The method of claim 1, wherein the target Pass pipeline includes at least one custom Pass defined using a second infrastructure provided by the MLIR framework for performing at least one optimization operation on the dialect IR.

4. The method according to claim 3, wherein the at least one optimization operation includes at least one of the following optimization operations: predicate pushdown, full table scan replacement with primary key lookup, column pruning, and path pattern optimization.

5. The method of claim 3, wherein the second infrastructure comprises at least one of the following infrastructures: a Def-Use chain analysis tool, a Pass base class for defining Passes, a Pattern Rewriter base class for rewriting Inverse Responsives (IRs), and a Rewrite Pattern base class for defining IR rewriting rules.

6. The method according to claim 1, wherein the first infrastructure includes at least one of the following infrastructures: a dialect registration interface for registering dialects, an operation construction interface, a type system interface, and an attribute system interface.

7. The method according to any one of claims 1-6, further comprising: Determine the current query type of the graph query request; Configure the target Pass pipeline using the Pass manager based on the current query type.

8. The method according to claim 7, wherein the current query type is Online Transaction Processing (OLTP) or Online Analytical Processing (OLAP), and the target Pass pipelines configured for OLTP and OLAP respectively include different Pass sequences.

9. An apparatus for processing graph query requests based on multi-level intermediate representations, the apparatus comprising: The parsing and processing unit is used to convert graph query requests written using a graph query language into an abstract syntax tree (AST). The conversion processing unit is used to convert the AST into a dialect intermediate representation IR based on the target dialect set for the graph query language, using the first infrastructure provided by the multi-level intermediate representation (MLIR) framework, which also provides a Pass manager. The optimization processing unit is used to optimize the dialect IR using the target Pass pipeline configured through the Pass manager, and convert the optimized dialect IR into a physical execution plan that can be executed by the graph query engine of the graph database.

10. A computing device comprising a memory and a processor, wherein the memory stores a computer program, and the processor, when executing the computer program, implements the method of any one of claims 1-8.

Images