Multi-step query execution in SQL server

Abstract

Methods, systems, and computer program products for constructing and executing multi-step query plans in a database application are provided. The database application accepts a query, such as, for example, a graph query. The database application generates a physical query plan that includes a set of execution steps to execute the query. The set of execution steps includes at least an initial step, an intermediate step, and a final step. The database executes the query by passing control to the initial step, and passing execution control to some other step when the initial step is completed. The intermediate step executes and, when completed, may pass execution control to any other step, including itself. Steps may be configured to transfer arbitrary data between steps. The generated query plan may also include multiple multi-step sequences, and such sequences may be configured to be executed alternately based on intermediate query results or parameters included in the query.

Description

Background Art

[0001] The modern digital world is experiencing exponential growth in the amount of data associated with every aspect of business and personal life. Solutions for the efficient storage and recall of such information are urgently needed. Businesses in particular need to transform the collected and stored data into actionable intelligence. Relational database systems and applications written to utilize such systems are the traditional tools for describing, storing, and retrieving business information. Recently, however, the demand for graph database systems has increased.

[0002] Instead of the traditional columns and rows of relational database tables, graph databases store data in the form of nodes and edges. Nodes represent different data values ​​or sets of related values, and edges connect nodes to represent the relationship between them. Edges may also have one or more related values ​​(such as the duration of the relationship). For example, data related to a company's employees can be represented by a node for each employee, and edges can connect employees who collaborate with each other, thereby representing a partner relationship. In another example, an edge connecting a buyer and a product can represent a product purchase and can have attributes such as sales price, quantity, date, etc. A complete picture of all nodes with all interconnected edges is called a graph.

[0003] In some cases, it may be desirable to store information in the form of a graph (as opposed to a native relational database table) and to perform graph queries. For example, graph storage may be desirable when a business application or its underlying data involves complex many-to-many relationships, or any time analysis of the relationships underlying the data is required (i.e., when the relationships between data points are as important or more important than the data points themselves). In these cases, graph storage and query capabilities may be useful because graph database systems often allow people to express certain types of queries more easily. For example, pattern matching, multi-hop navigation, transitive closure, and polymorphic queries are often easier to express using graph queries.

[0004] Relational database systems are increasingly being utilized to perform the functions of graph database systems. Specifically, the nodes and edges comprising a graph may be stored in common relational tables referred to as node and edge tables. The node table stores information or references related to a particular node (e.g., an employee), and the edge table reflects the relationships between the nodes in the node table (e.g., collaborators). However, such use of a relational database system may reveal certain problems.

[0005] For example, performing a shortest path graph query on a relational database requires repeatedly recursively connecting multiple tables, where each connection sequence represents a path extension. Relational database systems are generally not able to perform such queries themselves. In order to perform such queries, users may be forced to customize queries using conditional branches and temporary storage, which may bring significant performance issues. Similarly, writing such conditional logic is error-prone and requires new code for each new query. Alternatively, although these recursive common table expressions ("CTEs") suffer from performance issues, they can be used to handle at least the recursive part of the custom query. In addition, the recursive members of the CTE will typically recurse until no rows are returned, which means that it may be difficult to terminate early. Summary of the invention

[0006] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0007] Methods, systems, and computer-readable memory devices are provided that address problems associated with efficient execution of graph queries and other types of queries in relational database systems by providing a multi-step sequence query plan operator. In one aspect, a database application is configured to accept and process a query to generate a query plan comprising a multi-step sequence, wherein the multi-step sequence comprises at least: an initial step configured to execute and pass execution control to another step; an intermediate step configured to execute and pass execution control to another step; and a final step configured to execute to provide sub-query results based on the execution results of the above steps of the multi-step sequence. In one aspect, the sub-query results form at least a portion of the basis for the results of the received query. The intermediate step may include a recursive step configured to generate a recursive step result and pass such a result back to itself via recursion unless or until an early termination condition is met.

[0008] In one aspect, the relational database application may also generate one or more additional multi-step sequences for the query plan and determine which multi-step sequence to execute. The relational database application may determine which multi-step sequence to execute based at least in part on: a step result of another step of the query plan, an intermediate query result of any other multi-step sequence in the query plan, and / or the inclusion of optional parameters included in the query.

[0009] In another aspect, the multi-step sequence of a query plan may include a step configured to transfer arbitrary data to one or more other execution steps in the same or different multi-step sequence of the query plan. The multi-step sequence in the query plan may also include multiple sub-plans, each of which generates a corresponding sub-plan result when executed, and wherein the sub-plan result for a first sub-plan may be incorporated into another sub-plan and at least partially form the basis of the sub-plan result of the sub-plan. In addition, the sub-plan result for a first sub-plan may be reused by other sub-plans or steps without re-executing the first sub-plan.

[0010] Other features and advantages of the embodiments and the structure and operation of various embodiments are described in detail below with reference to the accompanying drawings. It should be noted that the embodiments are not limited to the specific embodiments described herein. Such embodiments are presented herein only for illustrative purposes. Based on the teachings contained herein, additional embodiments will be apparent to those skilled in the art(s). BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, serve to explain the principles of the embodiments and enable those skilled in the relevant art to make and use the embodiments.

[0012] Attached Figure 1 An example graph is shown, which reflects the collaborator relationships (edges) between workers (nodes).

[0013] Attached Figure 2 An example relational database node table is shown, which describes the Figure 1 The properties associated with the nodes shown in the graph.

[0014] Attached Figure 3 An example relational database edge table is shown, which describes the Figure 1 As shown in the attached Figure 2 The node table reflects how the nodes are connected.

[0015] Attached Figure 4 An example graph query that may be submitted to and processed by an example embodiment is shown.

[0016] Attached Figure 5 The diagram shows the various constraints by adding Figure 1 A table of possible traversal paths for the nodes of a graph.

[0017] Attached Figure 6 An example multi-step sequence is shown according to one embodiment.

[0018] Attached Figure 7 A block diagram of an example relational database system according to one embodiment is shown, the example relational database system including a multi-step query plan generator and a multi-step query plan executor, the multi-step query plan generator and the multi-step query plan executor being configured to respectively generate and execute a query plan including a multi-step sequence.

[0019] Attached Figure 8 A query according to one embodiment is shown, the query including repeated MATCH expressions and a conceptually efficient query generated by transformation of the query.

[0020] Attached Fig. 9 A portion of a SHOWPLAN output of a query plan including a multi-step sequence as generated by one embodiment for an example graph query is shown.

[0021] Attached Fig.10 A flow chart of a method for processing a query to generate and execute a physical query plan including a first multi-step sequence is shown according to an example embodiment.

[0022] Attached Fig.11 A flow chart of a method for processing a query by generating a physical query plan including a second multi-step sequence and for determining which of a first multi-step sequence and a second multi-step sequence to execute is shown according to an example embodiment.

[0023] Attached Fig.12 A flow chart of a method for determining which of a first multi-step sequence and a second multi-step sequence to execute is shown according to an example embodiment.

[0024] Attached Fig.13 A flow chart illustrating an alternative method for determining which of a first multi-step sequence and a second multi-step sequence to execute according to an example embodiment is shown.

[0025] Attached Fig.14 A flow chart of a method of processing a query by generating a query plan comprising a multi-step sequence including steps configured to pass data to one or more other steps of the query plan according to an example embodiment is shown.

[0026] Attached Fig.15 A flowchart of a method for processing a query by generating a query plan according to an example embodiment is shown, the query plan also including a first sub-plan and a second sub-plan, the first sub-plan and the second sub-plan being respectively configured to generate sub-plan results, and wherein the second sub-plan reuses the sub-plan results of the first sub-plan during subsequent execution.

[0027] Attached Fig.16A flow chart of a method for processing a query by regenerating a portion of a query plan during execution of the query plan is shown.

[0028] Attached Fig.17 is a block diagram of an example processor-based computer system that may be used to implement various embodiments.

[0029] Features and advantages of the embodiments described herein will become more apparent from the detailed description set forth below when taken in conjunction with the accompanying drawings, in which like reference numerals identify corresponding elements throughout the text. In the accompanying drawings, like reference numerals generally denote identical functionally similar and / or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference numeral. DETAILED DESCRIPTION

[0030] I. Introduction

[0031] This specification and the accompanying drawings disclose one or more embodiments that incorporate the features of the disclosed embodiments. The scope of the embodiments is not limited to the aspects disclosed herein. The disclosed embodiments are merely illustrative of the intended scope, and modified versions of the disclosed embodiments are also covered. The embodiments are defined by the appended claims.

[0032] References in the specification to "one aspect," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include the particular feature, structure, or characteristic. In addition, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of a person skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0033] Many exemplary embodiments are described below. It should be noted that any section / subsection title provided herein is not intended to be limiting. Embodiments are described throughout this document, and any type of embodiment may be included under any section / subsection. In addition, the embodiments disclosed in any section / subsection may be combined in any manner with any other embodiment described in the same section / subsection and / or different sections / subsections.

[0034] II. Example Embodiments

[0035] Embodiments will now be generally described with respect to performing a graph query against graph data stored as a node table and an edge table in a relational database. Specifically, embodiments will be described in terms of generating a query plan to perform a recursive shortest path traversal of a graph. However, it should be understood that embodiments are not limited to performing graph queries or recursive queries, as will be discussed in more detail below. Figure 1 Embodiments are described.

[0036] Attached Figure 1 An example graph 100 is shown, which reflects the collaborator relationships (edges) between workers (nodes). Figure 1 The example graph 100 includes nodes N1-node N4 enumerated using reference numerals 102-reference numeral 108, respectively. The example graph 100 also includes edges 1-edge 4 enumerated using reference numerals 110-reference numeral 116, respectively. As briefly described above, node N1 102 to node N4 108 represent workers of a company. On the other hand, edges 1 110 to edge 4 116 represent relationships between workers. In this example, the edges represent a "working together" relationship. That is, the nodes connected by the edges are workers with a collaborator relationship (i.e., they collaborate with each other). Figure 1 The example graph 100 is a conceptual visualization tool only. The data representing the example graph 100 must be in the same format as the attached Figure 1 The examples shown in FIG. 100 are stored differently.

[0037] For example, Figure 2 An example relational database node table 200 is shown, which describes the Figure 1 The node table 200 is stored as a table in a relational database and is named "employee" in this example. The node table 200 includes three columns that store information related to each node. Specifically, each row of the node table 200 includes a node ID, an employee name, and a role. The employee name at each node only reflects the name of the employee. Figure 1 In the example graph 100 of , the employee names included in each node (ie, row of the table) are only abbreviations. In an actual graph reflecting actual production data, one may expect to see the real names of the personnel.

[0038] Each node in the node table 200 also includes the role of that particular employee. For example, the employee illustrated by the nodes in the example diagram 100 and embodied in the node table 200 may be an architect as shown at node N1 102 or node N3 106, a receptionist as shown at node N2 104, or a PM (i.e., "program manager") as shown at node N4 108. Each node included in the node table 200 also includes a node ID, which uniquely identifies each node and, as described below, is also used to identify the employee assigned to the node by the attached node. Figure 3 The edge table has 300 edges connecting the nodes.

[0039] Attached Figure 3The edge table 300 can also be stored in a relational database together with the node table 200. In this example, the edge table 300 is named "collaboration". The edge table 300 includes three columns for defining each edge. The columns are: edge ID, from node, and to node. Each row corresponds to an edge of the example graph 100. The node ID in each row uniquely identifies each edge. The from node of each row includes the node ID of one of the nodes connected by the edge, and the to node includes the node ID of another node connected by the edge. Note that in this example, the node table reflects the "to" and "from" relationships (i.e., a directed graph). However, it should be understood that the embodiments can be used with any type of graph, directed graph, or other type of Figure 1 Play a role.

[0040] Combine the node table 200 and the edge table 300, and refer to the attached Figure 1 , it can be seen that these tables reflect the nodes of the example graph 100 and the edges used to interconnect such nodes. In an embodiment, after the node table 200 and the edge table 300 have been created and persisted to the relational database system, a user may seek to perform graph queries against the data.

[0041] For example, Figure 4 An example graph query 400 is shown that may be submitted to and processed by an example embodiment. Figure 5 The following description is attached Figure 4 Attached Figure 5 The diagram shows the various constraints by adding Figure 1 Table 500 of possible traversal paths of nodes of a graph of FIG. In an embodiment, immediately below is a table of possible traversal paths of nodes of a graph of FIG. Figure 4 and attached Figure 5 The discussion is used to generally describe query 400 and the types of data that such a query can return. Details of other embodiments describing the processing of query 400 for generating a physical query plan will be discussed in more detail further below.

[0042] Attached Figure 4 Query 400 is an example Transact-SQL ("T-SQL") graph query according to one embodiment. Query 400 includes a statement that includes three clauses: SELECT clause 402, FROM clause 403, and WHERE clause 404. Query 400 acts as an implicit JOIN of the employee table, the collaborating table, and again the employee table, where the results are filtered by the WHERE clause 404. Note that because the query is computing a recursive result, embodiments must use the FROM clause 403 and the WHERE clause 404 (including the recursive MATCH predicate 406 discussed below) together to compute the result, rather than strictly computing a Cartesian product.

[0043] The WHERE clause 404 includes three conditions or predicates 406, 408, and 410. Predicate 406 specifies a recursive MATCH condition that will only include the shortest paths between the starting node n1 and the ending node n2, where node n1 and node n2 satisfy predicate 408 and predicate 410, respectively. Predicate 408 requires that the role of each matching starting node is equal to 'architect'. Similarly, predicate 410 requires that the role of each matching ending node is equal to 'PM'. The query result of query 400 is then generated by applying the conditions of the WHERE clause 404 to the results of the SELECT statement 402. Specifically, the query result will return the shortest path between each architect and each program manager, as shown in the attached figure. Figure 1 As shown in the example graph 100 of , and as embodied by the node table 200 and the edge table 300 .

[0044] By considering the Figure 5 The query results of query 400 can be better understood. Figure 5 Table 500 shows the various constraints by adding Figure 1 Table 500 includes three columns, including: all paths 502, all paths between architects and program managers 504, and the shortest path between all architects and program managers 506. Figure 5 The paths shown in table 500 of assume that no node can be traversed more than once. However, it should be understood that no specific traversal constraints or rules are required or assumed. For example, a similar traversal table can be created assuming that no edge can be traversed more than once, or where loops (loops / cycles) are allowed to reach a certain maximum path length.

[0045] The first column of table 500 shows all possible traversal paths from each node through all paths to all other nodes in example graph 100. Figure 1100, consider the upper left quadrant of column 502, which shows 5 paths starting at node N1 102 of example graph 100 and ending at each of other nodes N2-N4. Specifically, the paths include: N1 to N2, N1 to N2 to N3, N1 to N2 to N3 to N4, N1 to N2 to N4, and N1 to N2 to N4 to N3. It can be shown that this is an exhaustive list of possible traversal paths from N1 to other nodes N2-node N4 (and in which no cycle / loop of traversing nodes more than once is allowed in any path). The paths from N2, N3 and N4 to all other nodes are illustrated in the upper right, lower left and lower right quadrants of column 502 of table 500, respectively. This exhaustive list of traversal paths is provided only for context and completeness, since, for example, the traversal of example graph 100 required to evaluate query 400 would not typically start at any node other than architect (i.e., N1 and N3). However, in an embodiment, a bidirectional traversal may be performed, whereby example graph 100 is traversed in both directions starting at both architect and program manager (but no other nodes) and working until the traversals meet in the middle.

[0046] Consider now column 504 of table 500, where constraints are placed on the traversal path. Figure 1 The traversal path of the example diagram 100 is shown in FIG. 100 , where the start node is limited to the architect and the end node is limited to the program manager. Figure 2 As shown in the node table 200 of example graph 100, there is only one employee with the role of PM, which corresponds to node N4 108. Therefore, all paths in column 504 must end on N4. Similarly, only N1 and N3 of example graph 100 correspond to employees with the role of architect, which then requires that the paths in column 504 must always start at either node N1 or node N3. Obviously, the paths in column 504 are an exhaustive list of such paths.

[0047] Finally, consider column 506 of table 500, in which additional constraints are imposed on the otherwise valid traversal paths shown in column 504. Specifically, the paths shown in column 506 not only satisfy the conditions required to produce the paths in column 504, but also constitute the shortest paths between all architects and all program managers (as measured by the number of hops, since in this case the edges all have equal weight). Thus, there is only one path between N1 and N4 and between N3 and N4, and these paths are the shortest paths between the corresponding endpoints. The paths shown in column 506 are based on the additional Figure 4 The query returns 400 rows.

[0048] Although it can be noted that Figure 5The ordering of the paths shown in Table 500 suggests a depth-first traversal of the example graph 100, but it should be understood that embodiments are not limited to any particular traversal algorithm. In fact, as is understood in the art, the algorithm employed to perform the traversal may vary depending on the type of graph (e.g., weighted edges, negative edge weights) and / or the specific type of shortest path problem being solved. In embodiments, shortest path algorithms may include Dykstra's algorithm, Bellman-Ford algorithm, A* search algorithm, Floyd-Warshall algorithm, Johnson algorithm, Viterbi algorithm, and other algorithms as known in the art. Embodiments may implement recursive versions of one or more of these algorithms to perform the shortest path traversal that is necessary to execute query 400 and may be performed in a variety of ways. For example, the attached Figure 6 An example multi-step sequence 602 is shown according to an example embodiment, which can be included in a physical query plan for executing graph queries and other types of queries. Based on the following discussion of the multi-step sequence 602, other structural and operational embodiments will be apparent to those skilled in the relevant art(s).

[0049] In one embodiment, multi-step sequence 602 is a logical and physical sequence operator that can be included in a query plan. Figure 6 The multi-step sequence 602 depicted in FIG. 6 includes an initial step 606, an intermediate step 608, and a final step 610. Although the multi-step sequence 602 is shown in FIG. Figure 6 602, but such a configuration is illustrated as a typical example, and other embodiments of the multi-step sequence may include fewer steps or a greater number of execution steps. In addition, a multi-step sequence may include more than one final step where the particular final step to be executed is left as a runtime decision. Note that a multi-step sequence may also be a single step that is repeated one or more times. Other embodiments involve only a single step being present. Each of steps 606 and 608 may be configured to pass execution control to one or more other steps of the multi-step sequence 602 via one or more execution paths 614-624. The final step 610 is configured to pass execution control and the query sub-results 612 back to a query execution component, such as a multi-step query plan executor 714 of a query execution engine 712, as shown in the attached Figure 7 606, step 608, and step 610. However, it should be understood that embodiments of multi-step sequence 602 are not limited to multi-step sequences that include only these specific steps or step types. Figure 6 Embodiments are described.

[0050] In the embodiments, Figure 6 The multi-step sequence 602 can be understood by viewing an instance of the multi-step sequence 602 as a normal sequence operator but with relaxed execution constraints and extended inter-step communication capabilities. Normal sequence operators typically drive extensive update plans and execute each child of the sequence in pure sequence order from the first to the last. Each child of such a sequence typically updates a different object and returns only those rows generated by the last child of the sequence.

[0051] On the other hand, a multi-step sequence, such as multi-step sequence 602, is a more flexible sequence operator with many different capabilities. For example, an embodiment of multi-step sequence 602, when included in an executable physical query plan, may enable one or more of the following capabilities depending on the details of the generated multi-step sequence:

[0052] ● Break down query plans into individual steps that can be executed in any order and repeated to allow flexible, efficient recursive execution;

[0053] ● Pass arbitrary data between steps, including full or partial result sets;

[0054] ● Multiple alternative plans for one or more steps, where the execution selection between plans is deferred until execution (e.g., serial vs. parallel plans, depending on which plan is chosen during execution).

[0055] the determined base number);

[0056] ● Adaptation between steps, including parallelism, to account for high memory requirements

[0057] Overestimated or underestimated adaptive memory grants, cardinality estimates; and

[0058] ●Suitability for many applications, including: interleaved execution, parameter-sensitive scheduling and / or bidirectional execution.

[0059] In an embodiment, the initial step 606, the intermediate step 608, and the final step 610 of the multi-step sequence 602 may each include a single physical or logical SQL query operator. However, in some other embodiments, the steps of the multi-step sequence 602 may include one or more physical or logical SQL query operators. In one embodiment, the physical operator may include any type of physical operator, such as, for example, hash matching, table insertion, merge join, nested loop, index insertion, non-clustered index update, parallelism, sorting, splitting, stream aggregation, table scan, and other types of SQL physical operators as may be known in the art. In an embodiment, the logical query operator may include, for example, branch and segment repartitioning, various join operators, distinct and distinct sort, partial aggregation, union, and other types of SQL logical operators as known in the art.

[0060] When executing a query plan that includes an instance of the multi-step sequence 602, the initial step 606 of the multi-step sequence 602 is the first step of the multi-step sequence to be executed. In one embodiment, the initial step 606 is configured to execute to generate an initial step result and then pass execution control to a different step or to itself. However, in some embodiments, depending on the step result generated by the initial step 606, execution control may be passed to any other step including the intermediate step 608 by passing execution control via the execution path 616. Similarly, the initial step 606 may pass execution control to the final step 610 via the execution path 618. Alternatively, the initial step 606 may pass execution control to a different step that may be included in the multi-step sequence 602 and as described by the attached steps. Figure 6 602. A set of vertical ellipses depicted in 602 represent any other steps (including final step 610, a step that determines that execution should terminate) (execution path not shown). For purposes of describing an embodiment of multi-step sequence 602, it is assumed herein that initial step 606 passes execution control to intermediate step 608 via execution path 616.

[0061] In the embodiments, Figure 6An intermediate step 608 of a multi-step sequence 602 in can be configured to receive execution control from a previously executed step of the multi-step sequence 602. After receiving the execution control, an embodiment including the intermediate step 608 can be configured to execute to generate an intermediate step result, and hereinafter pass execution control to any other step in the multi-step sequence 602, including the intermediate step 608 itself. An embodiment can include several useful features enabled by allowing multi-step sequence steps (such as the intermediate step 608) to execute themselves. For example, in an embodiment, recursive queries (such as such a recursive shortest path graph query discussed above) can be implemented in a simple manner without requiring a user to custom craft a recursive query or a recursive CTE, and thereby also avoiding performance issues associated with those solutions. Additionally, by permitting intermediate step 608 (and other instances of intermediate steps similar to intermediate step 608) to pass execution control to any other step in multi-step sequence 602, multi-step sequence 602, in an embodiment, is enabled to execute steps in any order, to execute alternative sub-plans based on actual step results determined at runtime, to adapt to the memory or performance requirements of a query based on cardinality estimates calculated at runtime, and to enable other features as discussed above.

[0062] After execution to generate the intermediate step result, the intermediate step 608 can pass execution control to any other step of the multi-step sequence 602. The intermediate step 608 can only run once to generate the intermediate step result, and thereafter the execution control is passed to another step. Similarly, even if the intermediate step 608 is recursively executed (i.e., by repeating itself to operate the result generated by the previous iteration), usually the terminal condition or recursive depth limit will be reached in the end, and the intermediate step 608 will pass execution control to some other step. Note that in some other embodiments, the step can be repeated and not terminated (i.e., infinite loop). For the purpose of describing the embodiment of the multi-step sequence 602, it is assumed in this article that the intermediate step 608 passes execution control to the final step 610 via the execution path 618.

[0063] In the embodiments, Figure 6The final step 610 of the multi-step sequence 602 in the multi-step sequence 602 can be configured to receive execution control from any previously executed step of the multi-step sequence 602 (including from the intermediate step 608) via the execution path 618. The final step 610 of the multi-step sequence 602 is configured to be the final execution step in the multi-step sequence 602. In an embodiment, the final step 610 is configured to generate a query sub-result 612, which includes the results for the entire execution of the multi-step sequence 602. In an embodiment, the query sub-result 612 can be based in part on any previous step results generated by the steps of the multi-step sequence 602. After receiving the execution control and generating the query sub-result 612, an embodiment of the multi-step sequence 602 is enabled to pass the query sub-result 612 and execution control to any other query operator, step, step sequence, or multi-step sequence, or back to the query execution engine (e.g., an attached Figure 7 602 , as will be discussed in further detail below). Embodiments may generate and incorporate instances of multi-step sequence 602 into a query plan for execution plan 100 , and may do so in a variety of ways.

[0064] For example, Figure 7 A block diagram of an example relational database system 702 is shown according to an example embodiment that includes a multi-step query plan generator 710 configured to generate queries that include the multi-step sequence 602. Other structural and operational embodiments will be apparent to those skilled in the relevant art(s) based on the following discussion of the relational database system 702.

[0065] The relational database system 702 includes a query preprocessor 706, a query optimizer 708, a query execution engine 712, and (multiple) relational data stores 716. The query optimizer 708 includes a multi-step query plan generator 710. The query execution engine 712 includes a multi-step query plan executor 714. The query preprocessor 706 is coupled to the query generation entity 704. These features of the relational database system 702 are described as follows.

[0066] In the embodiment, as shown in the attached Figure 7 The query preprocessor 706 of the relational database system 702 shown in FIG. 4 is configured to accept the query 400 from the query generation entity 704. For illustrative purposes, the following is a description of the query preprocessor 706 with respect to the query generated by the query generation entity 704 as an appendix. Figure 4The relational database system 702 is described with reference to a query 400 received by the relational database system 702, but in embodiments, other queries may be received and processed by the system 702. The query generation entity 704 may provide the query 400 locally to the relational database system 702 (e.g., from a terminal or Microsoft SQL Server Management Studio), or remotely via a network (such as, for example, the Internet). However, the network may include one or more networks, such as a local area network (LAN), a wide area network (WAN), an enterprise network, and may include one or more of wired and / or wireless portions. Examples of computing devices that may be used to provide queries to the relational database system 702 include, for example, but are not limited to, desktop computers, laptop computers, tablet computers, netbooks, smart phones, wearable computing devices, and the like.

[0067] Although the relational database system 702 is described as a monolithic component, the relational database system 702 may also be implemented as any number of computing devices including servers, and may include any type and number of other resources, including resources that support communication with computing devices connected via a network as described above and between these computing devices. In an embodiment, the servers implementing the relational database system 702 may be organized in any manner, including being grouped into server racks (e.g., 8 to 40 servers per rack, referred to as nodes or "blade servers"), server clusters (e.g., 2 to 64 servers, 4 to 8 racks, etc.), or data centers (e.g., thousands of servers, hundreds of racks, dozens of clusters, etc.). In an embodiment, the servers including the relational database system 702 may be co-located (e.g., housed in one or more nearby buildings with associated components (such as backup power, redundant data communications, environmental control, etc.)) to form a data center, or may be arranged in other ways. Therefore, in an embodiment, the relational database system 702 may include a data center in a distributed collection of data centers.

[0068] As attached Figure 7As shown in , the query preprocessor 706 is configured to receive the query 400 submitted by the query generation entity 704, and perform certain operations thereon to generate a representation of the query suitable for further processing by the query optimizer 708. Such operations may include, but are not limited to, parser and algebraizer operations performed by parser and algebraizer components (not shown for simplicity of illustration). In one embodiment, the query preprocessor 706 outputs a query processor tree 718, which is a logical representation of the query 400. In one embodiment, the query processor tree 718 can be obtained by translating the original text of the query 400 into a tree structure having leaf nodes representing table accesses and internal nodes representing relational operators (such as relational joins). The query optimizer 708 is configured to receive the query processor tree 718 output by the query preprocessor 706, and process the query processor tree 718 to generate a query plan 720 for the query. In particular, an embodiment of the relational database system 702 and the multi-step query plan generator 710 of the query optimizer 708 will now be generally described. The query processor tree 718 will be obtained by translating the original text of the query 400 into a tree structure having leaf nodes representing table accesses and internal nodes representing relational operators (such as relational joins). Figure 4 Such an embodiment is described in terms of query 400, generating a query including the attached Figure 6 The query plan 720 of the example of the multi-step sequence 602 is used to execute the query 400. However, it should be understood that the embodiment of the relational database system 702 is not strictly limited to the embodiment of the embodiment of the relational database system 702 as shown in the attached figure. Figure 6 Referring now to the multi-step sequence illustrated in FIG. Figure 4 and attached Figure 6 Embodiments are described.

[0069] For convenience, query 400 is reproduced herein below:

[0070] SELECT*FROM Employees n1, WorkingWith e1, Employees n2

[0071] WHERE MATCH(shortest_path(n1(-(e1)->n2)+)and

[0072] n1.Role=′Architect′and

[0073] n2.Role=′PM′

[0074] The query plan 720 generated for executing the query 400 begins with the query preprocessor 706, where the text of the T-SQL query 400 is parsed to determine in part whether the query 400 includes a repeated MATCH expression. For example, the query 400 includes the following repeated MATCH expressions:

[0075] MATCH(shortest_path(n1(-(e1)->n2)+)

[0076] In an embodiment, when the parser encounters repeated MATCH expressions in a query, the query is marked to indicate that a recursive multi-step sequence should be used to generate a query plan 720 .

[0077] In one embodiment, when an incoming query requires a recursive multi-step sequence, such as in the case of query 400, query preprocessor 706 of relational database system 702 is configured to perform an initial transformation of query 400 into query parts necessary to generate the recursive multi-step sequence that is incorporated into query plan 720. In particular, each repeated MATCH expression must be mapped to an anchor member, a recursive member, and an outer SELECT query that explicitly references the recursive member in a manner similar to a recursive CTE.

[0078] Embodiments of the query preprocessor 706 may also be configured to expand repeated MATCH expressions in both left-to-right and right-to-left directions, wherein embodiments allow queries to execute repeated MATCH expressions in either direction, for example:

[0079] MATCH(shortest_path(n1(-(e1)->n2<-(e2)-n3)+))

[0080] In an embodiment, the above-mentioned transformations and expansions may be performed in part by a query preprocessor 706 of the relational database system 702 to produce a query processor tree 718 as provided to a query optimizer 708. An embodiment of the query optimizer 708 may be configured to use the multi-step query plan generator 710 to generate a query plan 720 when the query optimizer 708 determines that the query plan 720 should include an instance of the multi-step sequence 602. For example, and as discussed above, the parser functionality of the query preprocessor 706 may include a flag in the query processor tree 718, as provided to the query optimizer 708, and indicate specific processing required to evaluate the query 400. In an embodiment, the query optimizer 708 may thereafter detect the flag in the query processor tree 718 and direct the multi-step query plan generator 710 to create a recursive multi-step sequence for inclusion in the query plan 720.

[0081] As discussed above, embodiments of query preprocessor 706 may be configured to perform, for example, an initial transformation of query 802 to expand the repeated MATCH portion of query 802 into at least an anchor member, a recursive member, and an outer selection query. Figure 8 Attached Figure 8802 according to one embodiment, the query 802 includes repeated MATCH expressions and conceptually valid queries generated by transformations of the query. Figure 8 The query 802 is reproduced below:

[0082] SELECT*FROM n1, n2, n3, e1, e2

[0083] WHERE MATCH(shortest_path(n1(-(e1)->n2-(e2)->n3)+))

[0084] Attached Figure 8 The effective query 804 shows the conceptual expansion of the query 802 and its repeated matching predicates (i.e., "match(shortest_path(n1(-(e1)->n2-(e2)->n3)+)") into equivalent anchor members 808, recursive members 810, and outer selection queries 812. It should be understood that the effective query 804 represents a non-physical conceptual transformation and does not represent the query from which the query plan 720 was generated.

[0085] In the embodiments, Figure 7 The relational database system 702 may use the query preprocessor, query optimizer 708, multi-step query plan generator 710, query execution engine 712, and multi-step query plan executor 714 in various ways to generate a query plan including a multi-step sequence, and such a sequence may likewise include various logical and physical plan operators, as discussed above. For example, the attached Fig. 9 900 for a query plan, including a multi-step sequence 906 as generated by one embodiment for an example graph query. The multi-step sequence 906 as shown in the SHOWPLAN output 900 is extracted from a physical query plan generated by one embodiment of the relational database system 702 and includes various logical and physical plan operators. Figure 4 The query 400 and attached Figure 6 The multi-step sequence 602 is used to describe the attached Fig. 9 SHOWPLAN output 900.

[0086] Graph query 902 is substantially the same as the attached Figure 4400. In an embodiment, the FOR PATH option is used to mark the associated aliases for later verification. Specifically, any aliases that begin with the FOR PATH option must be used in MATCH expressions that are repeated in the query. Therefore, the corresponding query plans created for these queries will be the same, and all discussions of query 400 herein apply equally to the attached Fig. 9 902 and all other discussions of SHOWPLAN output 900, instead of referring to query 400 and the attached Figure 4 .

[0087] Multi-step sequence 906 is attached Figure 6 602, as discussed in detail above. In SHOWPLAN output 900, multi-step sequence 906 is represented by sequence SHOWPLAN operator 904. As discussed above, a multi-step sequence can be considered a special type of sequence, and although sequence SHOWPLAN operator 904 is labeled "sequence", it still operates as a multi-step sequence, as described in more detail below.

[0088] As detailed above and in the attached Figure 6 , an embodiment of a multi-step sequence includes at least an initial step, an intermediate step, and a final step. Multi-step sequence 904 includes five steps: predicate step 908, predicate step 910, recursive setup step 912, recursive step 914, and final step 916. In multi-step sequence 904, predicate step 908 is used as the first step. Each of predicate step 910, recursive setup step 912, and recursive step 914 is an intermediate step. Final step 916 includes the final step of multi-step sequence 904. For convenience, reference will be made to the attached Figure 4 Each of these steps is discussed with query 400, which is reproduced herein below:

[0089] SELECT * FROM

[0090] Employee n1,

[0091] WorkingWith e1,

[0092] Employee n2

[0093] WHERE MATCH(shortest_path(n1(-(e1)->n2)+)and

[0094] n1.Role=′Architect′and

[0095] n2.Role=′PM′

[0096] Attached Fig. 9 Predicate step 908 and predicate step 910 of perform query operations related to predicate 408 and predicate 410, respectively. Predicate step 908 finds all starting nodes for the shortest path traversal of the example graph 100. More specifically, predicate step 908 finds all rows in the employee table where 'role' is equal to 'architect' and stores these rows in a temporary table. Similarly, predicate step 910 finds all ending nodes for the shortest path traversal graph 110. More specifically, predicate step 910 finds all rows in the employee table where 'role' is equal to 'PM' and stores these rows in a temporary table. Although predicate step 908 is the first step of the multi-step sequence 906, predicate step 910 can be used just as easily as the initial step because these operations are independent of each other. Similarly, and for the same reason, predicate step 908 and predicate step 910 can be executed simultaneously. In any event, no matter which of predicate step 908 and predicate step 910 is executed the second time, the step will be considered an intermediate step.

[0097] Recursive setup step 912 is also an intermediate step. Recursive setup step 912 is the beginning of the path traversal. Recursive setup step 912 finds all nodes that are one hop away from each of the starting nodes. More specifically, recursive setup step 912 retrieves the results stored in the temporary table by predicate step 908, determines which rows are one hop away from each of those nodes, and stores those results in the temporary table. Figure 1 Example Figure 100 and attached Figure 2 Node table 200, it can be seen that node N1 and node N3 are the starting nodes as determined by predicate step 908, and recursive setup step 912 determines node N2 as the only node one hop away from node N1, and node N2 and node N4 are determined as nodes one hop away from node N3. After recursive setup step 912 stores these results in a temporary table, execution control is passed to recursive step 914.

[0098] Recursive step 914 is configured to recursively traverse the nodes of example graph 100 to determine the shortest path between each architect and each PM. More specifically, recursive step 914 starts with the results of recursively setting step 912 (i.e., the nodes that are one hop away from the starting node), and determines the nodes that are one hop away from those nodes, and continues to recursively execute recursive step 914 to find all nodes of the next level until no more nodes are found. Alternatively, and when traversing in a breadth-first manner, the recursion can be terminated when a path is found and / or when all possible results are found. During each iteration of recursive step 914, the found nodes are stored in a temporary table, and at the end of the recursion, the temporary table will contain the entire result set.

[0099] Final step 916 retrieves the result set from the temporary table used by recursive step 914 and bubbles those results through the rest of the query plan (not shown).

[0100] In the embodiments, Figure 7 The relational database system 702 can be used in various ways to perform graph queries or other types of queries using a multi-step sequence. Fig.10 A flowchart 1000 of a method for processing a query to generate and execute a physical query plan including a first multi-step sequence according to an example embodiment of a relational database system 702 is shown. Figure 7 Describe the flowchart 1000. Based on the following description of the flowchart 1000 and the attached Figure 7 Based on the discussion of relational database system 702, other structural and operational embodiments will be apparent to those skilled in the relevant art(s).

[0101] Flowchart 1000 begins with step 1002. In step 1002, a query is received in a database application. Figure 7 In a relational database system 702, a query preprocessor 706 receives a query 400 from a query generation entity 704. As described above, the query 400 may include, for example, a T-SQL query.

[0102] In step 1004, the query is processed to generate a query plan, the query plan comprising at least a first set of execution steps, the first set of execution steps being configured to be executed to generate a first query sub-result, and wherein the first set of execution steps comprises the following other steps:

[0103] ● Initial steps, configured to be executed to generate the first step after receiving execution control

[0104] step results and passing execution control to a step different from the initial step;

[0105] = at least one intermediate step configured to generate a second step result after receiving execution control and pass execution control to any step in the set of execution steps; and

[0106] A final step configured to generate a first query sub-result based at least in part on the initial step result and the intermediate step result after receiving the execution control.

[0107] For example, in the attached Figure 7In the relational database system 702, the query preprocessor 706 can be configured to preprocess the query 400 to generate a query processor tree 718, which is received by the query optimizer 708. In conjunction with the multi-step query plan generator 710, the query optimizer 708 is configured to generate a query plan 720 that includes an instance of the multi-step sequence 602, all of which are described in detail above.

[0108] Flowchart 1000 continues at step 1006. At step 1006, the query plan is executed by passing execution control to an initial step in a set of execution steps of the query plan to generate a final query result based at least in part on the first query sub-result. For example, and as discussed above, query optimizer 708 of relational database system 702 is configured to pass query plan 720 to query execution engine 712. Query plan 720 includes an instance of multi-step sequence 602. For example, query plan 720 may include an example similar to the following: Fig. 9 In an embodiment, the multi-step query plan executor 714 of the query execution engine 712 may be configured to execute the query plan 720 by passing execution control to the first step in the query plan. The first step in the query plan may include, for example, Figure 6 606 of the multi-step sequence 602 shown in FIG. Fig. 9 In the case where the multi-step sequence 906 is operated in the same manner, the multi-step query plan executor 714 of the query execution engine 712 passes execution control to the predicate step 908 of the multi-step sequence 906, which serves as the initial step discussed above at step 1004.

[0109] The multi-step sequence 906 is executed to determine the starting node for the graph traversal required to compute the graph query 902, as discussed in detail above. Such starting nodes are stored in a temporary table and include the first step results discussed above with respect to step 1004. After executing the predicate step 908 of the multi-step sequence 906, the multi-step query plan executor 714 of the query execution engine 712 is configured to pass execution control to the intermediate step, as discussed above with respect to step 1004.

[0110] For example, the multi-step query plan executor 714 of the query execution engine 712 may pass execution control to the predicate step 910 of the multi-step sequence 906. After execution of the predicate step 910 is completed, the multi-step query plan executor 714 of the query execution engine 712 may and will pass execution control to the next step in the multi-step sequence 906, in this case the recursive setup step 912. Once execution of the recursive setup step 912 is completed, execution control may be passed to the recursive step 914.

[0111] As discussed above, recursive step 914 is configured to recursively traverse the base graph in a manner indicated by the details of query 400 and store the results in a temporary table. The final step 916 of multi-step sequence 906 is configured to generate a first query sub-result as discussed above with respect to step 1004. More specifically, final step 916 should retrieve the final result determined at recursive step 914 and return such result as the first query sub-result. By the foregoing description, the first query sub-result is based at least in part on the initial step result (i.e., the starting node of the traversal) and the intermediate step result (i.e., the result of the graph traversal).

[0112] After completing execution of multi-step sequence 906, query execution engine 912 may pass execution control to the next step (if any) in query plan 720. Figure 6 and attached Fig. 9 As can be appreciated from the detailed description, the final query result generated at step 1006 must be based at least in part on the first query sub-result generated by, for example, the multi-step sequence 906.

[0113] In the foregoing discussion of steps 1002-1006 of flowchart 1000, it should also be understood that, at times, such steps may be performed in a different order or even concurrently with other steps. For example, in an embodiment, the execution step of processing the query to generate a query plan in step 1004 may be performed with different portions of such generation being performed in parallel.

[0114] As mentioned above, Figure 7 The relational database system 702 of the relational database system 702 can operate in various ways to process queries. For example, in an embodiment, the query preprocessor 706, the query optimizer 708, and the multi-step query plan generator 710 can operate according to the flowchart 1000 and optionally perform additional steps. For example, in performing the following steps, Fig.10 During or after the method steps of the flowchart 1000 shown in FIG. 1 , an embodiment of the relational database system 702 may be configured to perform the following operations: Fig.11 -Attached Fig.16 Please operate according to any of the accompanying drawings.

[0115] Attached Fig.11 A flowchart 1100 is depicted that illustrates an example method for processing a query by generating a query plan that includes a second multi-step sequence and determining which of a first multi-step sequence and a second multi-step sequence to execute, according to an example embodiment. Figure 7The flowchart 1100 is described with reference to the relational database system 702 of FIG. 1 , but the method is not limited to this implementation. Based on the following discussion of the flowchart 1100, other structural and operational embodiments will be apparent to those skilled in the relevant art(s).

[0116] In step 1102 of flowchart 1100, a query plan is generated to include a second set of execution steps, each of the first set of execution steps and the second set of execution steps are alternately executed to generate a first query sub-result, and processing the query includes determining which execution step in the set of execution steps to execute. Figure 7 The relational database system 702 of the embodiment of the present invention can receive a query 400 that requires a query plan 720 with an additional multi-step sequence 602, and each of the multi-step sequences can be executed alternately. For example, it may be difficult to determine before runtime whether a given query should be executed as a serial plan or as a parallel plan. The multi-step query plan generator 710 of the query optimizer 708 can be configured to detect such divergences and generate the query plan 720 to include both the serial plan and the parallel plan. Further, the query plan 720 can be configured to also include a step that can determine at runtime which plan to execute.

[0117] Attached Fig.12 The method for determining whether the above-mentioned Fig.11 Flowchart 1200 of a method for determining which of the first set of execution steps and the second set of execution steps to execute as discussed herein. Flowchart 1200 begins at step 1202. At step 1202, a determination is made as to which of the first set of execution steps and the second set of execution steps to execute based at least in part on the step results of any other execution steps of the query plan or the intermediate query results of any other set of execution steps of the query plan. For example, the query plan 720 generated by the query optimizer 708 in conjunction with the multi-step query plan generator 710 may include additional execution steps or additional sets of execution steps (e.g., a multi-step sequence), the results of which are used to determine which of the first multi-step sequence and the second multi-step sequence should be executed. Such steps or sets of execution steps may be configured, for example, to more accurately estimate or determine the cardinality of a portion of the query, and thereafter select a higher performing set of execution steps. An embodiment may determine which of the first set of execution steps and the second set of execution steps should be executed in another manner. For example, considering the additional Fig.13 Flowchart 1300.

[0118] Attached Fig.13A flowchart 1300 of an alternative method for determining which of a first set of execution steps and a second set of execution steps to execute is shown according to an example embodiment. The flowchart 1300 starts at step 1302. In step 1302, it is determined which of the first set of execution steps and the second set of execution steps to execute based at least in part on optional parameters included in the query. For example, as may be known to those skilled in the relevant art(s), parameters may be passed to the query through, for example, a stored procedure. In one embodiment of the relational database system 702, the query optimizer 708 and the multi-step query plan generator 710 may work in conjunction to generate a query plan 720 including a first set of execution steps and a second set of execution steps based at least in part on which parameters may be passed to the query via the stored procedure, and cache the query plan 720 for later use. During subsequent executions of the stored procedure, an embodiment of the relational database system 702 may use the parameters included in the call to the stored procedure to decide which of the first set of execution steps and the second set of execution steps should be executed.

[0119] Now turn to the attached Fig.14 , attached Fig.14 1400 is a flowchart of a method for processing a query by generating a physical query plan including a multi-step sequence including steps configured to pass data to one or more other steps of the query plan according to an example embodiment. As discussed above, embodiments of the relational database system 702 can be configured to use the query optimizer 708 in conjunction with the multi-step query plan generator 710 to generate query plans including multi-step sequences such as, for example, the multi-step sequence 906. As discussed above in conjunction with the accompanying Fig. 9 As discussed in the discussion of , the results of predicate step 908 are stored in a temporary table and thereafter used by recursive setup step 912, which, when executed, retrieves the results stored in the temporary table. In this way, data can be transferred from one step in a multi-step sequence to another step in the multi-step sequence. However, in addition to temporary tables, embodiments of multi-step query plan generator 710 can generate multi-step sequences in which steps are enabled to pass discrete scalar values ​​to other steps.

[0120] Embodiments of the relational database system 702 may also be based on the attached Fig.15 Operation. Fig.15 A flowchart 1500 of a method for processing a query to generate a query plan is shown, the query plan including a first sub-plan and a second sub-plan, the first sub-plan and the second sub-plan are respectively configured to generate sub-plan results, and wherein the second sub-plan reuses the sub-plan results of the first sub-plan during subsequent execution. Flowchart 1500 starts at step 1502.

[0121] At step 1502, a first sub-plan is generated that includes at least one execution step. For example, in an embodiment, the query optimizer 708 may operate in conjunction with the multi-step query plan generator 710 to generate the query plan 720 to include an execution step or a set of execution steps (i.e., a multi-step sequence). The operation of the flowchart 1500 continues at step 1504.

[0122] At step 1504, the first sub-plan is executed to generate a first sub-plan result. For example, and as described above in conjunction with at least Figure 6 , Attachment Figure 7 and attached Fig. 9 As discussed in the discussion above, an instance of multi-step sequence 602 may be executed by multi-step query plan executor 714 of query execution engine 712 to generate query sub-results.

[0123] At step 1506, a second sub-plan including at least one execution step is generated based at least in part on the first sub-plan result, the second sub-plan being configured to generate the second sub-plan result when executed by the query execution engine, and wherein any subsequent execution of the second sub-plan will reuse the first sub-plan result. In one embodiment, the query optimizer 708 and the multi-step query generator 710 of the relational database system 702 may be configured to generate a multi-step sequence 602 that depends at least in part on the query sub-result. Such a multi-step sequence may include the second sub-plan of step 1506. Of course, the execution of the second sub-plan (which may be a multi-step sequence) itself will generate the second sub-plan result. An embodiment of the query optimizer 708 may be configured to cache the second sub-plan for reuse for subsequent executions of the plan, and there is no need to rerun the first sub-plan to obtain the first sub-plan result.

[0124] Alternatively, the embodiment may be based on the attached Fig.16 1600 is functionally illustrated, illustrating a method for processing a query by regenerating a portion of a query plan during execution of the query plan. Flowchart 1600 begins at step 1602. At step 1602, a portion of a query plan is regenerated during execution of the query plan. For example, an embodiment of relational database system 702 in conjunction with query optimizer 708 and multi-step query plan generator 710 may generate a query plan 720 including a first multi-step sequence and a second multi-step sequence 602. During execution of query plan 720, an embodiment may cause, for example, a portion of query plan 720 corresponding to the second multi-step sequence to be recompiled. Such runtime recompilation may be advantageous in the event that query optimizer 708 makes incorrect assumptions during optimization of the query to generate query plan 720, and such incorrect assumptions may be discovered by executing the first multi-step sequence.

[0125] Note that, for example, the foregoing general description of the operation of relational database system 702 is provided, and embodiments of relational database system 702 may operate in a manner other than that described above. Fig.10 -Attached Fig.16 All steps of flowcharts 1000-1600 need to be performed in all embodiments. In addition, the steps of flowcharts 1000 and 1500 can be performed in an order different from the order shown in some embodiments.

[0126] III. Example Computer System Implementation

[0127] The relational database system 702, flowchart 1000, flowchart 1100, flowchart 1200, flowchart 1300, and / or flowchart 1400, flowchart 1500, and / or flowchart 1600 can be implemented in hardware, or hardware combined with software and / or firmware. For example, the relational database system 702, flowchart 800, flowchart 900, flowchart 1000, flowchart 1100, flowchart 1200, flowchart 1300, and / or flowchart 1400 can be implemented as computer program code / instructions, which are configured to be executed in one or more processors and stored in a computer-readable storage medium. Alternatively, the relational database system 702, flowchart 1000, flowchart 1100, flowchart 1200, flowchart 1300, flowchart 1400, flowchart 1500, and / or flowchart 1600 can be implemented as hardware logic / electrical circuit devices.

[0128] For example, in one embodiment, one or more of relational database system 702, flowchart 1000, flowchart 1100, flowchart 1200, flowchart 1300, flowchart 1400, flowchart 1500, and / or flowchart 1600, in any combination, may be implemented together in a SoC. A SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), a microcontroller, a microprocessor, a digital signal processor (DSP), etc.), a memory, one or more communication interfaces, and / or other circuits, and may optionally execute received program code and / or include embedded firmware to perform functions.

[0129] Attached Fig.17An exemplary implementation of a computing device 1700 in which an embodiment may be implemented is depicted. For example, the relational database system 702 may be implemented using one or more computing devices similar to the computing device 1700 in the fixed or mobile computer embodiment (including one or more features and / or alternative features of the computing device 1700). The description of the computing device 1700 provided herein is provided for the purpose of illustration and is not intended to be limiting. As known to those skilled in the relevant art(s), the embodiments may be implemented in other types of computer systems.

[0130] As attached Fig.17 As shown in FIG. 1 , computing device 1700 includes one or more processors referred to as processor circuits 1702, system memory 1704, and a bus 1706 coupling various system components including system memory 1704 to processor circuits 1702. Processor circuits 1702 are electrical and / or optical circuits implemented as central processing units (CPUs), microcontrollers, microprocessors, and / or other physical hardware processor circuits in one or more physical hardware circuit device elements and / or integrated circuit devices (semiconductor material chips or dies). Processor circuits 1702 can execute program codes stored in computer-readable media, such as program codes of operating systems 1730, application programs 1732, other programs 1734, and the like. Bus 1706 represents any one or more of several types of bus structures, including memory buses or memory controllers, peripheral buses, accelerated graphics ports, and processor or local buses using any of a variety of bus architectures. System memory 1704 includes read-only memory (ROM) 1708 and random access memory (RAM) 1710. A basic input / output system 1712 (BIOS) is stored in ROM 1708 .

[0131] The computing device 1700 also has one or more of the following drives: a hard disk drive 1714 for reading from and writing to a hard disk, a disk drive 1716 for reading from or writing to a removable disk 1718, and an optical disk drive 1720 (such as a CD ROM, DVD ROM, or other optical media) for reading from or writing to a removable optical disk 1722. The hard disk drive 1714, the disk drive 1716, and the optical disk drive 1720 are connected to the bus 1706 via a hard disk drive interface 1724, a disk drive interface 1726, and an optical disk drive interface 1728, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer. Although a hard disk, a removable disk, and a removable optical disk are described, other types of hardware-based computer-readable storage media may be used to store data, such as flash memory cards, digital video disks, RAM, ROM, and other hardware storage media.

[0132] A plurality of program modules may be stored on a hard disk, a magnetic disk, an optical disk, a ROM, or a RAM. These programs include an operating system 1730, one or more application programs 1732, other programs 1734, and program data 1736. Application programs 1732 or other programs 1734 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing relational database system 702, flowchart 800, flowchart 900, flowchart 1000, flowchart 1100, flowchart 1200, flowchart 1300, and / or flowchart 1400 and / or other embodiments described herein.

[0133] A user may enter commands and information into the computing device 1700 through input devices such as a keyboard 1738 and a pointing device 1740. Other input devices (not shown) may include a microphone, a joystick, a game pad, a satellite dish, a scanner, a touch screen and / or touchpad, a voice recognition system for receiving voice input, a gesture recognition system for receiving gesture input, etc. These and other input devices are typically connected to the processor circuit 1702 through a serial port interface 1742 coupled to the bus 1706, but may be connected through other interfaces such as a parallel port, a game port, or a universal serial bus (USB).

[0134] Display screen 1744 is also connected to bus 1706 via an interface, such as video adapter 1746. Display screen 1744 may be external to computing device 1700 or incorporated into computing device 1700. Display screen 1744 may display information as well as serve as a user interface for receiving user commands and / or other information (e.g., through touch, finger gestures, a virtual keyboard, etc.). In addition to display screen 1744, computing device 1700 may include other peripheral output devices (not shown), such as speakers and printers.

[0135] The computing device 1700 is connected to a network 1748 (e.g., the Internet) through an adapter or network interface 1750, a modem 1752, or other means for establishing communications over the network. The modem 1752 (which may be internal or external) may be connected to the bus 1706 via a serial port interface 1742, such as the attached Fig.17 , or may be connected to bus 1706 using another interface type including a parallel interface.

[0136] As used herein, the terms "computer program medium", "computer readable medium" and "computer readable storage medium" are used to refer to physical hardware media (such as a hard disk associated with hard disk drive 1714, removable disk 1718, removable optical disk 1722), other physical hardware media (such as, for example, RAM, ROM, flash memory card, digital video disk, compact disk, MEM, nanotechnology-based storage devices) and other types of physical / tangible hardware storage media. Such computer readable storage media are distinguished from and do not overlap with communication media (excluding communication media). Communication media implement computer readable instructions, data structures, program modules or other data in a modulated data signal (such as a carrier wave). The term "modulated data signal" means a signal whose one or more characteristics are set or changed in a manner that encodes the information in the signal. By way of example and not limitation, communication media include wireless media (such as acoustic wireless media, RF wireless media, infrared wireless media and other wireless media) and wired media. Embodiments also relate to such communication media that are separate from and do not overlap with embodiments involving computer readable storage media.

[0137] As described above, computer programs and modules (including application programs 1732 and other programs 1734) can be stored on a hard disk, disk, optical disk, ROM, RAM or other hardware storage medium. Such computer programs can also be received via network interface 1750, serial port interface 1742 or any other interface type. When executed or loaded by an application, such computer programs enable computing device 1700 to implement the features of the embodiments described herein. Therefore, such computer programs represent the controller of computing device 1700.

[0138] Embodiments also relate to computer program products including computer codes or instructions stored on any computer readable medium.Such computer program products include hard disk drives, optical disk drives, storage device packages, portable memory sticks, memory cards, and other types of physical storage hardware.

[0139] VI. Additional Example Embodiments

[0140] In one embodiment, a system is provided. The system includes: a query preprocessor configured to receive a query and construct a logical operator query tree; a query optimizer configured to generate an executable query plan based at least in part on the logical operator query tree, the executable query plan at least including a set of execution steps configured to be executed to generate a first query sub-result, the execution step set including: an initial step configured to be executed to generate a first step result after receiving an execution control, and to pass the execution control to a step different from the initial step; at least one intermediate step configured to generate a second step result after receiving the execution control, and to pass the execution control to any step in the execution step set; and a final step configured to generate a first query sub-result based at least in part on the initial step result and the intermediate step result after receiving the execution control; and a query execution engine configured to execute the query by passing the execution control to the initial step in the execution step set of the executable query plan to generate a final query result based at least in part on the first query sub-result.

[0141] In an embodiment of the aforementioned system, the executable query plan further includes: a second set of execution steps configured to generate a second query sub-result; and the query execution is configured to execute the query to further generate a final query result based at least in part on the second query sub-result.

[0142] In another embodiment of the foregoing system, the at least one intermediate step is further configured to pass execution control to any execution step in the executable query plan.

[0143] In one embodiment of the aforementioned system, the query optimizer is configured to generate an executable query plan to include an execution step configured to pass data to one or more other execution steps in the executable query plan.

[0144] In another embodiment of the aforementioned system, the query optimizer is further configured to generate an executable query plan by including a third set of execution steps and a fourth set of execution steps, each of the third set of execution steps and the fourth set of execution steps being configured to be executed alternately; and the query execution engine is further configured to determine which of the third set of execution steps and the fourth set of execution steps to execute when the executable query plan is being executed.

[0145] In one embodiment of the aforementioned system, the query execution engine is configured to determine which of the third set of execution steps and the fourth set of execution steps to execute based at least in part on at least one of: a step result of any execution step of the executable query plan, or an intermediate query result of any other set of execution steps of the executable query plan.

[0146] In another embodiment of the foregoing system, the query execution engine is configured to determine which of the third set of execution steps and the fourth set of execution steps to execute based at least in part on whether the optional parameter is included in the query.

[0147] In one embodiment of the aforementioned system, in order to generate an executable query plan, the query optimizer is further configured to: generate a first sub-plan, the first sub-plan comprising at least one execution step, the at least one execution step being configured to generate a first sub-plan result; execute the first sub-plan to generate the first sub-plan result; and generate a second sub-plan comprising at least one execution step based at least in part on the first sub-plan result, the second sub-plan being configured to generate a second sub-plan result when executed by the query execution engine, and wherein any subsequent execution of the second sub-plan will reuse the first sub-plan result.

[0148] In another embodiment of the foregoing system, the query optimizer is configured to regenerate at least a portion of the executable query plan during execution of the executable query plan.

[0149] A computer-implemented method for executing a query to generate a query result is provided. In one embodiment, the computer-implemented method includes: receiving a query in a database application; processing the query, wherein the processing the query includes: generating a query plan for the query, the query plan including at least the following set of execution steps, the set of execution steps configured to be executed to generate a first query sub-result, the set of execution steps including: an initial step configured to be executed to generate a first step result after receiving execution control, and passing execution control to a step different from the initial step; at least one intermediate step configured to generate a second step result after receiving execution control, and passing execution control to any step in the set of execution steps; and a final step configured to generate a first query sub-result based at least in part on the initial step result and the intermediate step result after receiving execution control; and executing the query by passing execution control to the initial step in the set of execution steps of the query plan. To generate a final query result based at least in part on the first query sub-result.

[0150] In one embodiment of the aforementioned method, the query plan also includes: a second set of execution steps configured to generate a second query sub-result; and wherein executing the query to generate the final query result also includes: executing the query to further generate the final query result based at least in part on the second query sub-result.

[0151] In one embodiment of the aforementioned method, at least one intermediate step comprises a recursive step configured to generate a recursive step result and pass execution control to itself unless the recursive step result satisfies a predefined condition.

[0152] In another embodiment of the aforementioned method, generating a query plan for a query includes generating the query plan to include an execution step configured to transmit data to one or more other execution steps in the query plan.

[0153] In one embodiment of the aforementioned method, generating a query plan for a query includes: generating a query plan to include a third set of execution steps and a fourth set of execution steps, each of the third set of execution steps and the fourth set of execution steps being configured to be executed alternately; and wherein processing the query also includes: determining which one of the third set of execution steps and the fourth set of execution steps to execute.

[0154] In another embodiment of the aforementioned method, the determining which one of the third set of execution steps and the fourth set of execution steps to execute includes: determining which one of the third set of execution steps and the fourth set of execution steps to execute based at least in part on at least one of the following: a step result of any other execution step of the query plan, or an intermediate query result of any other set of execution steps of the query plan.

[0155] In one embodiment of the aforementioned method, determining which of the third set of execution steps and the fourth set of execution steps to execute includes: determining which of the third set of execution steps and the fourth set of execution steps to execute based at least in part on an optional parameter included in the query.

[0156] In another embodiment of the aforementioned method, generating a query plan for a query also includes: generating a first sub-plan, the first sub-plan including at least one execution step, the at least one execution step being configured to generate a first sub-plan result; executing the first sub-plan to generate the first sub-plan result; and generating a second sub-plan including at least one execution step based at least in part on the first sub-plan result, the second sub-plan being configured to generate a second sub-plan result when executed by the query execution engine, and wherein any subsequent execution of the second sub-plan will reuse the first sub-plan result.

[0157] In an embodiment of the foregoing method, processing the query further comprises: regenerating at least a portion of the query plan during execution of the query plan.

[0158] In yet another embodiment, a computer readable storage device having computer program code recorded thereon is provided, the computer program code, when executed by at least one processor of a computing device, causing the at least one processor to perform operations.

[0159] In one embodiment of the aforementioned computer-readable storage device, an operation includes: receiving a query in a database application; processing the query, wherein the processing the query includes: generating a query plan for the query, the query plan including at least the following set of execution steps, the execution step set being configured to be executed to generate a first query sub-result, the execution step set including: an initial step, configured to be executed to generate a first step result after receiving execution control, and to pass execution control to a step different from the initial step; at least one intermediate step, configured to generate a second step result after receiving execution control, and to pass execution control to any step in the set of execution steps; and a final step, configured to generate a first query sub-result based at least in part on the initial step result and the intermediate step results after receiving execution control; and executing the query to generate a final query result based at least in part on the first query sub-result by passing execution control to the initial step in the set of execution steps of the query plan.

[0160] In another embodiment of the foregoing computer readable memory device, at least one intermediate step comprises a recursive step configured to generate a recursive step result and pass execution control to itself unless the recursive step result satisfies a predefined condition.

[0161] V. Conclusion

[0162] Although various embodiments of the present application have been described above, it should be understood that these embodiments are presented by way of example only and not limitation. (Multiple) persons skilled in the relevant art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of the present application as defined in the appended claims. Therefore, the breadth and scope of the present application should not be limited by any of the exemplary embodiments described above, but should only be defined according to the following claims and their equivalents.

Claims

1. A computer-implemented method for executing a query to generate query results, the method comprising: receiving a query in a database application; Processing the query, wherein processing the query comprises: Determining that the query includes a repeated MATCH expression; generating an executable query plan for the query, the executable query plan comprising a multi-step sequence operator, the multi-step sequence operator comprising a first set of execution steps and a second set of execution steps, the first set of execution steps comprising an initial step, at least one intermediate recursive step for executing the repeated MATCH expression, and a final step, the first set of execution steps and the second set of execution steps being configured to be executed alternately to generate a first query sub-result; and The executable query plan is executed to generate query results by: passing execution control to the initial step of the first set of execution steps after selection of the initial step; Executing the intermediate recursive step to generate an intermediate recursive step result; determining, based on the intermediate recursive step result, to which execution step in the first set of execution steps execution control should be passed; passing execution control to the determined execution step in the first set of execution steps; and The final step is performed to generate the query result based at least in part on the intermediate recursive step result.

2. The computer-implemented method of claim 1 , wherein said processing said query further comprises: It is determined which one of the first set of execution steps and the second set of execution steps is to be executed, and the determined first set of execution steps is selected.

3. The computer-implemented method of claim 2, wherein the determining which of the first set of execution steps and the second set of execution steps to perform comprises: Determining which of the first set of execution steps and the second set of execution steps to execute is based at least in part on at least one of: the step result of any execution step of the query plan, or The query results for any other set of execution steps of the query plan.

4. The computer-implemented method of claim 3, wherein the determining which of the first set of execution steps and the second set of execution steps to perform comprises: Based at least in part on an optional parameter included in the query, a determination is made as to which of the first set of execution steps and the second set of execution steps to execute.

5. The computer-implemented method of claim 2, wherein the multi-step sequence operator of the query plan further comprises: a third set of execution steps, configured to generate a second query sub-result; and The execution is configured to generate the query result based at least in part on the intermediate recursive step result after receiving the execution control, comprising: The final step is performed to generate the query result based further at least in part on the second query sub-result.

6. The computer-implemented method of claim 5, wherein the intermediate recursive step is configured to pass execution control to itself until the intermediate recursive step result satisfies a predefined condition.

7. The computer-implemented method of claim 1 , wherein said generating a query plan for said query further comprises: The query plan is generated to include an execution step configured to pass data to one or more other execution steps of the multi-step sequence operator of the query plan.

8. The computer-implemented method of claim 1 , wherein said processing said query further comprises: During execution of the query plan, at least a portion of the query plan is regenerated.

9. The computer-implemented method of claim 1, wherein the query is a graph query against graph data stored as nodes and edges in a relational database.

10. A system for executing a query to generate a query result, comprising: one or more processors; as well as Instructions encoded in one or more computer-readable media, wherein the instructions, when executed by the one or more processors, cause the system to perform operations comprising: Receive inquiries; Determining that the query includes a repeated MATCH expression; generating an executable query plan, the executable query plan comprising a physical multi-step sequence operator, the physical multi-step sequence operator comprising a first set of execution steps and a second set of execution steps, the first set of execution steps comprising an initial step, at least one intermediate recursive step for executing the repeated MATCH expression, and a final step, the first execution step and the second execution step each comprising a physical query plan operator and each configured to be executed alternately to generate a first query sub-result; and The executable query plan is executed to generate query results by: passing execution control to the initial step of the first set of execution steps after selection of the initial step; Executing the intermediate recursive step to generate an intermediate recursive step result; determining, based on the intermediate recursive step result, to which execution step in the first set of execution steps execution control should be passed; passing execution control to the determined execution step in the first set of execution steps; and The final step is performed to generate the query result based at least in part on the intermediate recursive step result.

11. The system of claim 10, wherein: The executing the executable query plan further includes determining which of the first set of execution steps and the second set of execution steps to execute when the executable query plan is being executed, and selecting the determined first set of execution steps.

12. The system of claim 11, wherein the determining which of the first set of execution steps and the second set of execution steps to perform is based at least in part on at least one of: the step result of any execution step of the executable query plan, or Intermediate query results of any other set of execution steps of the executable query plan.

13. The system of claim 11, wherein the determining which of the first set of execution steps and the second set of execution steps to perform is based at least in part on whether an optional parameter is included in the query.

14. The system of claim 11, wherein the multi-step sequence operator of the executable query plan further comprises a third set of execution steps configured to generate a second query sub-result; and the query result is also based at least in part on the second query sub-result.

15. The system of claim 14, wherein the at least one execution step is further configured to pass execution control to any execution step in the third set of execution steps.

16. The system of claim 10, wherein the executing the executable query plan further comprises regenerating at least a portion of the executable query plan during execution of the executable query plan.

17. The system of claim 10, wherein the executable query plan further comprises an execution step configured to pass data to one or more other execution steps of the multi-step sequence operator of the executable query plan.

18. The system of claim 10, wherein the intermediate recursive step is configured to pass execution control to itself until the intermediate recursive step result satisfies a predefined condition.

19. A computer readable memory device having computer program code recorded thereon, wherein the computer program code, when executed by at least one processor of a computing device, causes the at least one processor to perform operations, the operations comprising: receiving a query in a database application; Processing the query, wherein processing the query comprises: Determining that the query includes a repeated MATCH expression; generating an executable query plan for the query, the executable query plan comprising a multi-step sequence operator, the multi-step sequence operator comprising a first set of execution steps and a second set of execution steps, the first set of execution steps comprising an initial step, at least one intermediate recursive step for executing the repeated MATCH expression, and a final step, the first set of execution steps and the second set of execution steps being configured to be executed alternately to generate a first query sub-result; and The executable query plan is executed to generate query results by: passing execution control to the initial step of the first set of execution steps after selection of the initial step; Executing the intermediate recursive step to generate an intermediate recursive step result; determining, based on the intermediate recursive step result, to which execution step in the first set of execution steps execution control should be passed; passing execution control to the determined execution step in the set of execution steps; and The final step is performed to generate the query result based at least in part on the intermediate recursive step result.

20. The computer readable memory device of claim 19, wherein the intermediate recursive step is configured to pass execution control to itself until the intermediate recursive step result satisfies a predefined condition.

Images