Devices and methods for generating a query plan based on a SQL query
Patent Information
- Application Number
- EP2022818447
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2022-11-22
- Publication Date
- 2025-09-24
Smart Images
Figure 1.1
Abstract
Description
[0001] Devices and methods for generating a query plan based on a SQL query
[0002] TECHNICAL FIELD
[0003] The present disclosure relates to information processing technology. More specifically, the present disclosure relates to devices and methods for generating a query plan based on a SQL query.
[0004] BACKGROUND
[0005] Relational databases (RDBs) storing tabular relational data are a cornerstone of an increasing number of enterprises. RDB management systems (RDBMSs) are generally responsible for the management of the data, i.e., for the storage as well as retrieval of data. For retrieving data users may typically express their data retrieval needs in the form of the Structured Query Language (SQL), which is declarative, but not procedural. Thus, users only specify what they want but not how the results are to be retrieved. The sequence of steps that a RDBMS performs in order to fetch the data and present them to a user is generally called a query plan. For a given SQL query there may exist a multitude of equivalent query plans, and it is the job of a query optimizer of the RDBMS to either pick the computationally cheapest and efficient query plan or at least avoid the computationally expensive query plans. In other words, the query optimizer may discriminate query plans based on a cost model, which is used to estimate the query execution costs. Very often the most expensive operator in a query plan is the join operator, which is used to join two tables. Thus, for a SQL join expression joining n tables, there is a sequence of n-1 joins. It is the job of the query optimizer to come up with the most efficient query plan for this sequence of n-1 joins. Due to commutative and associative properties of joins, join expressions can be evaluated in multiple different ways, while all yield the same results. With the increase of the number of relations to be joined, the number of different but equivalent query plans increases exponentially. This makes the job of the query optimizer very difficult, especially in the presence of large join expressions. This is because, it has been shown that join order optimization in general is a NP-HARD problem. In other words, for large join expressions an exact solution to the join ordering problem cannot be found in reasonable time.
[0006] Nevertheless, join ordering remains one of the most important challenges in relational database systems and has been studied in great detail. With the general increase of the amount data and the widespread usage of, for instance, business intelligence tools, which often automatically generate queries, there is an even greater need for devices and methods providing efficient and scalable optimizers for optimizing queries, in particular queries involving large join expressions.
[0007] SUMMARY
[0008] It is an objective to provide improved devices and methods for generating a query plan based on a SQL query.
[0009] The foregoing and other objectives are achieved by the subject matter of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.
[0010] According to a first aspect a data processing apparatus is provided for determining a query plan based on a SQL query for a relational database (RDB). The query plan may define a sequence of steps used by an RDB management system (RDBMS) to fetch the results for the SQL query. The data processing apparatus is configured to generate a query graph based on the SQL query, wherein the query graph comprises a plurality of query graph nodes and a plurality of query graph edges, wherein each query graph node is connected by at least one query graph edge to at least one other query graph node. Moreover, the data processing apparatus is configured to generate a plurality of subgraphs of the query graph and to determine a local query plan for each of the plurality of subgraphs of the query graph. The data processing apparatus is further configured to determine, i.e. generate a composite global query plan for the query graph based on the local query plans for each of the plurality of subgraphs of the query graph, in particular by combining the local query plans for each of the plurality of subgraphs of the query graph. Thus, the data processing apparatus is configured to efficiently generate optimized query plans for SQL queries, in particular SQL queries involving large SQL join expressions.
[0011] In a further possible implementation form, the data processing apparatus is configured to generate the plurality of subgraphs of the query graph by removing one or more query graph edges of the query graph.
[0012] In a further possible implementation form, the data processing apparatus is configured to generate the plurality of subgraphs of the query graph by removing one or more query graph edges of the query graph by means of a graph cutting algorithm, for instance, the known Fiduccia-Mattheyses (FM) graph cutting algorithm or the known Kernighan-Lin (KL) graph cutting algorithm. In a further possible implementation form, for generating the plurality of subgraphs of the query graph the data processing apparatus is configured to recursively remove the one or more query graph edges of the query graph that have the lowest selectivities (i.e. the smallest filtering factor) of the plurality of query graph edges of the query graph. As used herein, generally selectivity refers to the probability of a Boolean predicate evaluating to true. In case of joins, the selectivity of a join condition e.g., between relation A and B may refer to the number of rows in the join result divided by the cross product of rows in relation A and B.
[0013] In a further possible implementation form, for generating the plurality of subgraphs of the query graph the data processing apparatus is configured to recursively remove the one or more query graph edges of the query graph that have the maximal or minimal values of a cost function of the plurality of query graph edges of the query graph.
[0014] In a further possible implementation form, the plurality of query graph edges comprises one or more query graph hyperedges and wherein the data processing is configured to not remove the one or more query graph hyperedges for generating the plurality of subgraphs of the query graph.
[0015] In a further possible implementation form, the data processing apparatus is further configured to determine the number of connected components of the query graph and to determine the local query plan for each of the plurality of subgraphs of the query graph, if the number of connected components of the query graph is equal to or larger than a threshold value.
[0016] In a further possible implementation form, the data processing apparatus is configured to determine, i.e. generate the composite global query plan for the query graph by determining the composite global query plan based on the whole uncut query graph, if the number of connected components of the query graph is smaller than the threshold value. In other words, if the number of connected components of the query graph is smaller than the threshold value, the query plan may be generated based on the original unprocessed query graph. In a further possible implementation form, the data processing apparatus is configured to determine the number of connected components of the query graph based on a graphcentric dynamic programming optimization algorithm.
[0017] In a further possible implementation form, for determining, i.e. generating the composite global query plan for the query graph the data processing apparatus is configured to combine the local query plans for each of the plurality of subgraphs of the query graph by considering each query plan for each of the plurality of subgraphs of the query graph as a base relation for a graph-centric dynamic programming optimization algorithm.
[0018] According to a second aspect a computer-implemented data processing method for determining a query plan based on a SQL query for a relational database is provided. The computer-implemented data processing method comprises the steps of: generating a query graph based on the SQL query, wherein the query graph comprises a plurality of query graph nodes and a plurality of query graph edges, wherein each query graph node is connected by at least one query graph edge to at least one other query graph node; determining a plurality of subgraphs of the query graph; determining a local query plan for each of the plurality of subgraphs of the query graph; and determining, i.e. generating a composite global query plan for the query graph based on the local query plan for each of the plurality of subgraphs of the query graph, for instance by combining the local query plans for each of the plurality of subgraphs of the query graph.
[0019] According to a third aspect a computer program product is provided, comprising a computer-readable storage medium for storing program code which causes a computer or a processor to perform the computer-implemented data processing method according to the second aspect when the program code is executed by the computer or the processor.
[0020] Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims.
[0021] BRIEF DESCRIPTION OF THE DRAWINGS
[0022] In the following, embodiments of the present disclosure are described in more detail with reference to the attached figures and drawings, in which: Fig. 1 shows a schematic diagram illustrating a data processing apparatus according to an embodiment for generating an optimized query plan based on a SQL query;
[0023] Fig. 2 illustrates an exemplary query graph generated by a data processing apparatus according to an embodiment;
[0024] Fig. 3 illustrates the generation of a plurality of subgraphs of a query graph and the processing of these subgraphs by a data processing apparatus according to an embodiment for generating an optimized query plan;
[0025] Fig. 4 illustrates a flow diagram illustrating processing steps implemented by a data processing apparatus according to an embodiment for generating an optimized query plan;
[0026] Fig. 5 illustrates a flow diagram illustrating processing steps for processing a SQL query by a data processing apparatus according to an embodiment; and
[0027] Fig. 6 is a flow diagram illustrating a computer-implemented data processing method according to an embodiment for generating an optimized query plan based on a SQL query.
[0028] In the following, identical reference signs refer to identical or at least functionally equivalent features.
[0029] DETAILED DESCRIPTION OF THE EMBODIMENTS
[0030] In the following description, reference is made to the accompanying figures, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the present disclosure or specific aspects in which embodiments of the present disclosure may be used. It is understood that embodiments of the present disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims.
[0031] For instance, it is to be understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and / or aspects described herein may be combined with each other, unless specifically noted otherwise.
[0032] Figure 1 shows a schematic diagram illustrating a data processing apparatus 100 according to an embodiment for generating an optimized query plan 150 based on a SQL query 140, in particular a SQL query 140 involving large join operations. The optimized query plan 150 may be executed by the data processing apparatus 100 or a different apparatus for obtaining query results from a relational database.
[0033] In an embodiment, the data processing apparatus 100 may be implemented, for instance, as a RDBMS, a cloud server interacting with a RDBMS or the like. As illustrated in figure 1 , the data processing apparatus 100 may comprise processing circuitry 110, e.g. one or more processors, a communication interface 120 and / or a memory 130. The processing circuitry 110 may be implemented in hardware and / or software and may comprise digital circuitry, or both analog and digital circuitry. Digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. The communication interface 120 may be configured to communicate with other network devices via wired and / or wireless connections. The memory 130 of the data processing apparatus 100 may be configured to store executable program code which, when executed by the processing circuitry 110, causes the data processing apparatus 100 to perform the functions and methods described herein.
[0034] As will be described in more detail below under further reference to figures 2 and 3, the processing circuitry 110 of the data processing apparatus 100 is configured to generate a query graph 200 based on the SQL query 140. By way of example, figure 2 illustrates a query graph 200 generated by the data processing apparatus 100 according to an embodiment. Generally, the query graph 200 comprises a plurality of query graph nodes 201 a-c and a plurality of query graph edges 203a-c, wherein each query graph node 201a- c is connected by at least one query graph edge 203a-c to at least one other query graph node 201 a-c. Mathematically, the query graph 200 can be described as a pair G(E,V) comprising the plurality of edges E 203a-c and the plurality of vertices V or nodes 201 a-c. The exemplary simple query graph 200 illustrated in figure 2 comprise three query graph nodes 201 a-c and three query graph edges 203a-c.
[0035] For the exemplary query graph 200 shown in figure 2 a simple SQL query 140 may be the following:
[0036] SELECT * FROM EMP, DEPT, CITY
[0037] WHERE EMP.did = DEPT.id
[0038] AND DEPT.cid = CITY.id
[0039] AND EMP.city = CITY.city;
[0040] This exemplary SQL query 140 joins the employee table with the department table, the department and the city tables as well as the employee table with the city table. In the query graph G(V, E) 200 relations (i.e. , tables) are represented by the nodes, i.e. vertices 201 a-c of the query graph 200, whereas joins by the edges 203a-c of the query graph 200.
[0041] As illustrated in figure 3, the processing circuitry 110 of the data processing apparatus 100 is further configured to generate a plurality of subgraphs 200a-c of the query graph 200. As used herein, each of the subgraphs 200a-c of the query graph 200 is a graph in itself with no edges connecting the respective subgraph to one of the other subgraphs. In the example shown in figure 3, which for illustration purposes shows a more complex exemplary query graph 200 than the query graph 200 shown in figure 2, the processing circuitry 110 of the data processing apparatus 100 is configured to divide the original query tree 200 into three unconnected subgraphs 200a-c. In the exemplary embodiment shown in figure 3 the processing circuitry 110 generates the three unconnected subgraphs 200a-c by removing the query graph edge 203a connecting the subgraph 200a with the subgraph 200b and by removing the query graph edges 203b and 203c connecting the subgraph 200b with the subgraph 200c.
[0042] In an embodiment, the processing circuitry 110 of the data processing apparatus 100 is configured to generate the plurality of unconnected subgraphs 200a-c of the query graph 200 by means of a graph cutting algorithm configured to remove one or more of the pluralities of query graph edges 203a-c of the query graph 200. For instance, the processing circuitry 110 of the data processing apparatus 100 may be configured to implement the Fiduccia-Mattheyses (FM) algorithm or the Kernighan-Lin (KL) algorithm. In the following different embodiments are described in more detail concerning the selection of the one or more of the pluralities of query graph edges 203a-c to be removed for generating the plurality of unconnected subgraphs 200a-c of the query graph 200. In an embodiment, the processing circuitry 110 of the data processing apparatus 100 may be configured to determine for each of the plurality of query graph edges 203a-c of the query graph 200 a cost function value and to remove those query graph edges 203a-c of the query graph 200 based on their respective cost function value, for instance, their respective selectivity. In an embodiment, the processing circuitry 110 of the data processing apparatus 100 may remove a certain number of the query graph edges 203a-c of the query graph 200 that have the smallest or largest cost function values for generating the plurality of unconnected subgraphs 200a-c of the query graph 200. As already mentioned, in an embodiment, the processing circuitry 110 of the data processing apparatus 100 may use a cost function based on the selectivity of the respective query graph edge 203a-c and to remove those query graph edges 203a-c of the query graph 200 that have the smallest selectivities. In other words, in an embodiment, the processing circuitry 110 of the data processing apparatus 100 may remove those query graph edges 203a-c that have a low selectivity factor, and continue to do so until the query graph 200 has been cut into disjoint subgraphs 200a-c.
[0043] More specifically, in an embodiment, the data processing apparatus 100 may be configured to partition the query graph 200 recursively into p partitions (disjoint subgraphs 200a-c) by maximizing the cost function: where C denotes the cost of the cut, and ftj, for instance, the selectivity of an edge 203a- c. In other words, in an embodiment, a balanced graph partitioning over non-selective edges 203a-c of the query graph 200 may be performed. As will be appreciated, graph partitioning is not a computationally expensive operation, that can be done efficiently in linear-time O(E). Thus, this operation is very efficient even when handling very large query graphs 200 containing thousands of nodes 201 a-c and edges 203a-c. This embodiment is based on the idea to cut the query graph 200 over the less selective join conditions represented by the corresponding graph edges 203a-c. Once the processing circuitry 110 of the data processing apparatus 100 has generated the plurality of unconnected subgraphs 200a-c, the processing circuitry 110 of the data processing apparatus 100 is further configured to determine a local or partial query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200. This is schematically illustrated on the right side of figure 3, where the processing circuitry 110 of the data processing apparatus 100 operates a plurality of threads 300a-c for processing each of the subgraphs 200a-c of the query graph 200 separately and determining the local or partial query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200. For an efficient computation of the plurality of local or partial query plans 205a-c the processing circuitry 110 of the data processing apparatus 100 may run the threads 300a-c substantially in parallel. In other words, each subgraph 200a-c can be solved in parallel in a multi-threaded fashion due to the graph partitions 200a-c being independent of one another. This way a multi-core architecture of the data processing apparatus 100 may be efficiently utilized and the optimization time significantly lowered. In an embodiment, each thread 300a-c may determine the local or partial query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200 using conventional dynamic programming algorithms, such as DPHyp.
[0044] Once every thread 300a-c has determined the local or partial query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200, the processing circuitry 110 of the data processing apparatus 100 is further configured to determine, i.e. generate a final composite global query plan 150 for the query graph 200 based on the plurality of local or partial query plans 205a-c of the plurality of subgraphs 200a-c of the query graph 200, as illustrated below the threads 300a-c shown in figure 3. In an embodiment, the processing circuitry 110 of the data processing apparatus 100 is configured to generate the final composite global query plan 150 by combining the local or partial query plans 205a-c of the plurality of subgraphs 200a-c of the query graph 200. In an embodiment, the data processing apparatus 100 is configured to combine the local or partial query plans 205a-c of the plurality of subgraphs 200a-c of the query graph 200 by considering each partial query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200 as a base relation for a graph-centric dynamic programming optimization algorithm, such as DPHyp.
[0045] In a further embodiment, the data processing apparatus 100 is further configured to determine the number of connected components (also non-as connected subgraphs) of the query graph 200 and to determine the local query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200, if the number of connected components of the query graph 200 is equal to or larger than a threshold value. Such an embodiment is shown in figure 4, where the number of connected components of the query graph 200 is denoted by S.
[0046] In a stage 401 and a stage 403 of the embodiment shown in figure 4, the data processing apparatus 100 is configured to parse the SQL query 140 and perform a semantic analysis for generating the query graph 200 based on the SQL query 140, as described above.
[0047] In a stage 405 of the embodiment shown in figure 4, the data processing apparatus 100 is configured to determine the number S of connected components of the query graph 200. In an embodiment, the data processing apparatus 100 is configured to determine the number S of connected components 200a-c of the query graph 200 based on a graph-centric dynamic programming optimization algorithm. For instance, in an embodiment, the data processing apparatus 100 may be configured to implement the DPHyp algorithm or a stripped-down version thereof for counting the number S of connected components of the query graph 200.
[0048] If the number S of connected components of the query graph 200 is equal to or larger than a threshold value (stage 407 of figure 4), the local query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200 are determined in the way already described above, namely by partitioning the query graph 200 into k disjoint subgraphs 200a-c (stage 409 of figure 4), by solving each subgraph 200a-c, i.e. generating the query plan 205a-c for each subgraph 200a-c in parallel (stage 411 of figure 4), and by solving, i.e. generating the final global query plan 150 over the solved partitions (stage 413 of figure 4). In an embodiment, the threshold value may have a size of about 10000 or more.
[0049] If in stage 407 of figure the number S of connected components of the query graph 200 is smaller than the threshold value (stage 407 of figure 4), the data processing apparatus 100 is configured to determine, i.e. generate the composite global query plan 150 for the query graph 200 by determining the composite global query plan 150 based on the whole uncut query graph 200. In other words, if the number S of connected components of the query graph 200 is smaller than the threshold value, the query plan 150 may be generated based on the original unprocessed query graph 200. Figure 5 illustrates a flow diagram illustrating processing steps for processing the SQL query 140 at least partially by the data processing apparatus 100 according to an embodiment. In a stage 501 and a stage 503 of the embodiment shown in figure 5 (which may correspond to the stages 401 and 403 of figure 4), the data processing apparatus 100 is configured to parse the SQL query 140 and perform a semantic analysis for generating the query graph 200 based on the SQL query 140, as described above. In a stage 505 of the embodiment shown in figure 5, the data processing apparatus 100 is configured to generate the optimized query plan 150 in the way described above. In a stage 507 of the embodiment shown in figure 5, the optimized query plan 150 is executed by a RDBMS to provide the query results. As already described above, the RDBMS may be a component of the data processing apparatus 100 or a separate entity in communication with the data processing apparatus 100.
[0050] In an embodiment, the data processing apparatus 100 may be configured to operate in accordance with the following pseudo code:
[0051] / / Input: Connected graph G,
[0052] / / Threshold ‘k’ of connected subgraphs
[0053] / / Output: Optimized plan
[0054] Plan Optimize(G(V,E) g, k) {
[0055] / / count connected subgraphs n = countCC(g) if (n <= k)
[0056] / / find the exact solution using graph-centric DP algorithm return dpHYP(g) else
[0057] / / compute the # of required graph partitions nr_p = n / k
[0058] Plan partial_pl = {} / / empty (partial) plan container graph [] partitions = partitionGraph(g, nr_p) / / runs in O(E) for each (g’ : partitions) partial_pl += async(dp / 7YP(g’)) / / solve in parallel
[0059] / / create a new query expression from partial plans (now acting as base / / relations) g_t = createQEXP(partial_plans) / / return the final solution over partial plans return dpHYP(g_ )
[0060] }
[0061] Figure 6 is a flow diagram illustrating a computer-implemented data processing method 600 for determining the query plan 150 based on the SQL query 140 for a relational database. The computer-implemented data processing method 600 comprises a first step 601 of generating the query graph 200 based on the SQL query 140, wherein, as already described above, the query graph 200 comprises the plurality of query graph nodes 201 a-c and the plurality of query graph edges 203a-c and wherein each query graph node 201 a-c is connected by at least one query graph edge 203a-c to at least one other query graph node 201 a-c. Moreover, the computer-implemented method 600 comprises a step 603 of determining a plurality of subgraphs 200a-c of the query graph 200 and a step 605 of determining the query plan 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200. The computer-implemented method 600 further comprises a step 607 of determining the query plan 150 for the query graph 200 based on the query plans 205a-c for each of the plurality of subgraphs 200a-c of the query graph 200.
[0062] As the computer-implemented data processing method 600 can be implemented by the data processing apparatus 100, further features of the computer-implemented data processing method 600 result directly from the functionality of the data processing apparatus 100 and its different embodiments described above and below.
[0063] As will be appreciated, embodiments disclosed herein provide an efficient and scalable approach for solving the problem of optimization of large join expressions. The algorithm implemented by embodiments disclosed herein is graph-centric and, thus, may work in tandem with state-of-the-art graph-centric dynamic programming optimization algorithms, such as DPHyp. In other words, once the graph representation 200 of the SQL query 140 has been obtained, the problem does not have to be transformed into another representation, this way saving valuable optimization time. By analyzing the graph structure 200 of the SQL query 140, its complexity may be inferred. Some queries 140, even if they join relatively large number of relations can nevertheless be solved exactly. This is for e.g., especially true for chain queries, i.e. queries defining a chain topology, which can be solved in polynomial time. Embodiments disclosed herein can efficiently optimize very large queries 140 containing thousands of relations due to its inherent parallelism. Embodiments disclosed herein employ graph cutting over non-selective edges 203a-c or over edges 203a- c minimizing any cost function. Graph cutting can be done very efficiently, as its complexity scales linearly with the number of edges 203a-c.
[0064] The person skilled in the art will understand that the "blocks" ("units") of the various figures (method and apparatus) represent or describe functionalities of embodiments of the present disclosure (rather than necessarily individual "units" in hardware or software) and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step).
[0065] In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. The described embodiment of an apparatus is merely exemplary. For example, the unit division is merely logical function division and may be another division in an actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.
[0066] The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments.
[0067] In addition, functional units in the embodiments disclosed herein may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.
Claims
CLAIMS1. A data processing apparatus (100) for determining a query plan (150) based on a SQL query (140) for a relational database, wherein the data processing apparatus (100) is configured to: generate a query graph (200) based on the SQL query (140), wherein the query graph (200) comprises a plurality of query graph nodes (201a-c) and a plurality of query graph edges (203a-c), wherein each query graph node (201 a-c) is connected by at least one query graph edge (203a-c) to at least one other query graph node (201 a-c); generate a plurality of subgraphs (200a-c) of the query graph (200); determine a query plan (205a-c) for each of the plurality of subgraphs (200a-c) of the query graph (200); and determine a query plan (150) for the query graph (200) based on the query plans (205a-c) for each of the plurality of subgraphs (200a-c) of the query graph (200).
2. The data processing apparatus (100) of claim 1 , wherein the data processing apparatus (100) is configured to generate the plurality of subgraphs (200a-c) of the query graph (200) by removing one or more of the plurality of query graph edges (203a-c) of the query graph (200).
3. The data processing apparatus (100) of claim 2, wherein the data processing apparatus (100) is configured to generate the plurality of subgraphs (200a-c) of the query graph (200) by removing one or more of the plurality of query graph edges (203a-c) of the query graph (200) by means of a graph cutting algorithm.
4. The data processing apparatus (100) of claim 2 or 3, wherein, for generating the plurality of subgraphs (200a-c) of the query graph (200), the data processing apparatus (100) is configured to remove the one or more of the plurality of query graph edges (203a- c) of the query graph (200) that have the smallest selectivities of the plurality of query graph edges (203a-c) of the query graph (200).
5. The data processing apparatus (100) of claim 2 or 3, wherein, for generating the plurality of subgraphs (200a-c) of the query graph (200), the data processing apparatus (100) is configured to remove the one or more of the plurality of query graph edges (203a- c) of the query graph (200) that have the maximal or minimal values of a cost function of the plurality of query graph edges (203a-c) of the query graph (200).
6. The data processing apparatus (100) of any one of claims 2 to 5, wherein the plurality of query graph edges (203a-c) comprises one or more query graph hyperedges and wherein the data processing apparatus (100) is configured to not remove the one or more query graph hyperedges for generating the plurality of subgraphs (203a-c) of the query graph (200).
7. The data processing apparatus (100) of any one of the preceding claims, wherein the data processing apparatus (100) is further configured to determine the number of connected components of the query graph (200) and to determine the query plan (205a-c) for each of the plurality of subgraphs (200a-c) of the query graph (200), if the number of connected components of the query graph (200) is equal to or larger than a threshold value.
8. The data processing apparatus (100) of claim 7, wherein the data processing apparatus (100) is configured to determine the query plan (150) for the query graph (200) by determining the query plan (150) based on the query graph (200), if the number of the connected components of the query graph (200) is smaller than the threshold value.
9. The data processing apparatus (100) of claim 7 or 8, wherein the data processing apparatus (100) is configured to determine the number of connected components of the query graph (200) based on a graph-centric dynamic programming optimization algorithm.
10. The data processing apparatus (100) of any one of the preceding claims, wherein the data processing apparatus (100) is configured, for determining the query plan (150) for the query graph (200), to combine the query plans (205a-c) for each of the plurality of subgraphs (200a-c) of the query graph (200) by considering each query plan (205a-c) for each of the plurality of subgraphs (200a-c) of the query graph (200) as a base relation for a graph-centric dynamic programming optimization algorithm.
11. A data processing method (600) for determining a query plan (150) based on a SQL query (140) for a relational database, wherein the data processing method (600) comprises: generating (601) a query graph (200) based on the SQL query (140), wherein the query graph (200) comprises a plurality of query graph nodes (201 a-c) and a plurality of query graph edges (203a-c), wherein each query graph node (201 a-c) is connected by at least one query graph edge (203a-c) to at least one other query graph node (201 a-c); determining (603) a plurality of subgraphs (200a-c) of the query graph (200);determining (605) a query plan (205a-c) for each of the plurality of subgraphs (200a-c) of the query graph (200); and determining (607) a query plan (150) for the query graph (200) based on the query plans (205a-c) for each of the plurality of subgraphs (200a-c) of the query graph (200).
12. A computer program product comprising a computer-readable storage medium for storing program code which causes a computer or a processor to perform the method (600) of claim 11 , when the program code is executed by the computer or the processor.