Method and devices for efficient plan search with bloom filters in a cost-based bottom-up optimizer

Abstract

There is provided a method for selecting an access plan in a cost-based bottom-up optimizer, where the access plan may comprise Bloom filters. In one embodiment, partial access plans with Bloom filter apply nodes are not joined with other partial plans unless the other partial plan can resolve the partial plan with the Bloom filter apply node. This reduces the search space for an optimal access plan to a manageable size and improves query completion run-times.

Description

METHOD AND DEVICES FOR EFFICIENT PLAN SEARCH WITH BLOOM FILTERS IN A COST-BASED BOTTOM-UP OPTIMIZER

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present application is the first application for this disclosure.

[0003] FIELD OF THE DISCLOSURE

[0004] The present disclosure relates to field of database technologies, and in particular to a method of efficiently selecting an access plan when Bloom filters are included during cost-based, bottom-up, optimization.BACKGROUND

[0005] When a Database Management System (DBMS) , receives a query, it may determine an optimal plan to satisfy the query. For example, assuming that the query requires data from different data tables, a plan may include selecting methods for scanning the data tables, an order in which the data tables may be joined to satisfy the query, and the method for joining different data tables. Each of these options have a cost associated thereto, and all the possible ways in which a query may be satisfied may be represented as individual trees called access plans, where each node in the tree represents an operation. In general, a DBMS will select the lowest cost solution to satisfy the query.SUMMARY

[0006] It is an object of the present disclosure to provide an improved method for efficiently selecting an access plan in a cost-based bottom-up optimizer when Bloom filters are incorporated in the costing.

[0007] According to a first aspect, there is provided a method for selecting an access plan, comprising a) receiving a query, the query comprising at least one predicate related to at least two tables; b) selecting Bloom filter candidates applying to at least one of the at least two tables; c) determining, for each Bloom filter candidate, a set of required inner tables; d) building a plurality of sub-plans for each of the at least two tables; e) selecting an outer sub-plan and an inner sub-plan from the plurality of sub-plans; when the outer sub-plan comprises a Bloom filter candidate, f) determining if the outer sub-plan and the inner sub-plan can be joined; and g) upon determining that the outer sub-plan and the inner sub-plan can be joined, joining the outer sub-plan with the inner sub-plan to create a new sub-plan.

[0008] According to an embodiment of the first aspect, determining if the outer sub-plan and the inner sub-plan can be joined comprises determining that the inner sub-plan can resolve the Bloom filter candidate of the outer sub-plan.

[0009] According to another embodiment of the first aspect, determining if the outer-sub-plan and the inner sub-plan can be joined comprises determining that the inner sub-plan produces a first set of inner tables; determining that the inner sub-plan requires a second set of inner tables; and determining that a combined set of the first set of inner tables and the second set of inner tables matches a set of inner tables required by the outer sub-plan.

[0010] According to yet another embodiment of the first aspect, joining the outer sub-plan with the inner sub-plan uses a hash join.

[0011] According to yet another embodiment of the first aspect, the method further comprises h) evaluating a cost for the new sub-plan based on a semi-join operation between the outer sub-plan and the inner sub-plan.

[0012] According to yet another embodiment of the first aspect, the method further comprises repeating steps d) , e) , f) , and g) with sub-plans from the plurality of new sub-plans, until the new sub-plans comprise at least one complete access plan.

[0013] According to yet another embodiment of the first aspect, the method further comprises selecting the access plan based on the cost of each of the at least one complete access plan; and executing the access plan.

[0014] According to yet another embodiment of the first aspect, step c) comprises building a sequence scan node for each of the at least one table; and building an index scan node for each of the at least one table.

[0015] According to yet another embodiment of the first aspect, if the outer plan does not comprise a Bloom filter candidate joining the outer sub-plan with the inner sub-plan with at least one of a hash join, a merge join, and a nest-loop join.

[0016] According to yet another embodiment of the first aspect, the method further comprises adding a Bloom filter apply node to sub-plans with Bloom filter candidates.

[0017] According to yet another embodiment of the first aspect, step g) comprises adding a Bloom filter build node to the inner sub-plan.

[0018] According to yet another embodiment of the first aspect, the method further comprises pruning the new sub-plan when the cost for the new sub-plan exceeds a cost of equivalent sub-plans.

[0019] According to a second aspect, there is provided a computing device comprising a processor and memory, the computing device being configured to perform the method of any embodiment of the first aspect.

[0020] According to a third aspect, there is provided a computer readable medium having stored thereon executable code for execution by a processor of a computing the device, the executable code comprising instructions for performing the method of any embodiment of the first aspect.

[0021] According to a fourth aspect, there is provided a method for selecting an access plan, comprising a) receiving a query, the query comprising at least one predicate related to at least one table; b) selecting Bloom filter candidates applying to at least one of the at least two tables; c) determining, for each Bloom filter candidate, a set of required inner tables; d) creating sub-plans for scanning each of the at least two tables; e) joining sub-plans without tables that are Bloom filter candidates; f) recursively processing sub-plans with tables that are Bloom filter candidates, wherein said recursive processing comprises when a given sub-plan is a leaf node i) joining the given sub-plan with other sub-plans when the Bloom filter is resolved by the other sub-plans to create a first set of new sub-plans; and ii) evaluating a cost of each of the first set of new sub-plans; otherwise, iii) recursively processing an inner sub-plan and an outer sub-plan of the given sub-plan to create a second set of new sub-plans; iv) joining sub-plans from the second set of the new sub-plans to create a third set of new sub-plans; and v) evaluating a cost of each of the third set of new sub-plans.

[0022] According to an embodiment of the fourth aspect, the method further comprises repeating step e) and f) until at least one complete access plan is created.

[0023] According to another embodiment of the fourth aspect, the method further comprises selecting the access plan based on the cost of each of the at least one complete access plan; and executing the access plan.

[0024] According to yet another embodiment of the fourth aspect, step i) uses a hash join.

[0025] According to yet another embodiment of the fourth aspect, step ii) evaluates the cost based on a semi-join operation of the given sub-plan with a selected sub-plan of the other sub-plans.

[0026] According to yet another embodiment of the fourth aspect, the method further comprises pruning sub-plans from the first set of new sub-plans.

[0027] According to yet another embodiment of the fourth aspect, the method further comprises pruning sub-plans from the third set of new sub-plans.

[0028] According to yet another embodiment of the fourth aspect, selecting Bloom filter candidates comprises selecting a largest table from a predicate of the at least one predicate.

[0029] According to a fifth aspect, there is provided a computing device comprising a processor and memory, the computing device being configured to perform the method of any embodiment of the fourth aspect.

[0030] According to a sixth aspect, there is provided a computer readable medium having stored thereon executable code for execution by a processor of a computing the device, the executable code comprising instructions for performing the method of any embodiment of the first aspect.BRIEF DESCRIPTION OF THE DRAWINGS

[0031] FIG. 1 is an illustration of data tables according to at least some embodiments of the present disclosure.

[0032] FIG. 2 illustrates a plurality of access plans according to at least some embodiments of the present disclosure.

[0033] FIG. 3A illustrates an unresolved partial plan according to at least some embodiments of the present disclosure.

[0034] FIG. 3B illustrates a resolved access plan according to at least some embodiments of the present disclosure.

[0035] FIG. 4 illustrates a flow chart for the first phase of the two-phase approach method, according to at least some embodiments of the present disclosure.

[0036] FIG. 5 illustrates example candidate plans with Bloom filter apply nodes added, according to at least some embodiments of the present disclosure.

[0037] FIG. 6 illustrates a flow chart for the second phase of the two-phase approach method, according to at least some embodiments of the present disclosure.

[0038] FIG. 7A illustrates a scenario where joining two sub-plans is allowed, according to at least some embodiments of the present disclosure.

[0039] FIG. 7B illustrates a complete access plan based on the joining of two sub-plans according to at least some embodiments of the present disclosure.

[0040] FIG. 8 illustrates a scenario where joining two sub-plans is allowed, according to at least some embodiments of the present disclosure.

[0041] FIG. 9 illustrates a scenario where joining two sub-plans is not allowed, according to at least some embodiments of the present disclosure.

[0042] FIG. 10 illustrates a flow chart for a method for selecting an access plan with the recursive approach according to at least some embodiments of the present disclosure.

[0043] FIG. 11 illustrates a flow chart for recursively building sub-plans according to at least some embodiments of the present disclosure.

[0044] FIG. 12 illustrates a sub-plan according to at least some embodiments of the present disclosure.

[0045] FIG. 13 is a block diagram of computing device according to at least one embodiment of the present disclosure.DETAILED DESCRIPTION

[0046] The present disclosure provides an improved method for selecting an access plan in a cost-based bottom-up optimizer when Bloom filters are incorporated in the costing.

[0047] Throughout the present disclosure, the following terminology will be followed.

[0048] Top-Down Optimizer: A top-down optimizer selects an access plan from the top down along the query tree, typically by applying rules to transform the query tree to get an optimal access plan.

[0049] Bottom-Up Optimizer: A bottom-up style optimizer constructs and selects an access plan from the bottom of the query tree, typically using dynamic programming or some other algorithm to get an optimal access plan.

[0050] Hash Join: Hash join is a method for joining data tables by building a hash table on relevant columns from one data table and probing the hash table for matching rows using the relevant columns from another data table.

[0051] Bloom Filter: A Bloom Filter is used to determine whether an element may be part of a set. Specifically, a Bloom Filter can indicate whether an element is not part of a set, or that an element might be part of a set. In the context of join operations, a bloom filter can be used to filter out unmatched rows early -before probing the hash table -thereby reducing the amount of data to be processed.

[0052] Reference is made to FIG. 1, which shows three data tables, 101, 102, and 103. The following example will be described assuming a query written in Sequenced Query Language (SQL) as follows: SELECT *FROM T1, T2, T3, WHERE T1. C1 = T2. C1, and T1. C3 = T3. C1 and T2. C2 = T3. C2, where T1, T2, and T3 represent tables 101, 102, and 103, respectively. This query will be used as an example throughout the present disclosure.

[0053] In order to select an access plan to satisfy the above query, different methods of scanning the tables, such as a sequence scan or an index scan may be examined, and the lowest cost option for each table selected. For the purposes of this example, it will be assumed that the lowest cost option for each data table is the sequence scan.

[0054] Then, a join order and a join mode may be determined. The join mode refers to different methods of joining tables. For example, the join mode may be a hash join, or a merge join, or a nest-loop join, without limitation. When a Bloom filter is applied, only hash joins are permissible. Throughout this disclosure, joins may be assumed to be hash joins unless explicitly stated.

[0055] To determine the optimal join order, each possible order is costed, as illustrated in FIG. 2. Specifically, as seen in FIG. 2, tree 201 represents a joining of table T1 with table T2, and the result of that joining operation is then joined with table T3. Notably, the order of the tables in a join operation may affect the cost of the operation, such that joining T1 with T2 may not have the same cost a joining T2 with T1. As such, tree 202 represents a joining of table T2 with table T1, and the result of that joining operation is then joined with table T3. Tree 203 represents a joining of table T1 with table T3, and the result of that joining operation is then joined with table T2. Tree 204 represents a joining of table T3 with table T1, and the result of that joining operation is then joined with table T2. Tree 205 represents a joining of table T3 with table T2, and the result of that joining operation is then joined with table T1.

[0056] Partial plans may be costed and discarded if their cost is excessive. For example, if joining T1 with T2 is found to be very beneficial over joining T2 with T1, the partial plan involving joining T2 with T1 may be discarded, and not used as the basis for further plans.

[0057] In order to reduce the cost of all the operation trees shown in FIG. 2, Bloom filters may be applied before a join operation. In particular, Bloom filters may be used to reduce the number of rows to be considered when performing join operations.

[0058] Using Bloom filters requires two separate operations, namely build, and apply. Building a Bloom filter from a data table involves hashing selected entries of the data table, using at least one hash function, where each hash produces an index of an array of bits. When a hash produces an index, the corresponding bit is set to 1. Applying a Bloom filter to a data table involves hashing selected entries of the data table using the same hash functions used during the building operation to produce indices, and checking if all the indices produced for a given entry have a bit set to 1.

[0059] As seen in FIG. 3A, a partial access plan may include a Bloom filter apply node 301. When a partial access plan includes an apply node, but no corresponding build node, this partial access plan is labeled as “unresolved” . As seen in FIG. 3B, a partial (or complete) access plan may also include a build node 303 in addition to an apply node 302. Because the access plan in FIG. 3B includes both the build node and the apply node, it is labeled as “resolved” .

[0060] Unresolved partial plans may not be costed as the cost of the build operation is not considered, and the cardinality of the result of the apply operation is unknown. However, these unresolved partial plans may not be discarded as they may still be the basis for the optimal access plan. Therefore, an unresolved partial plan may be used as the basis for many access plans, where every combination of join order, scan methods, and join modes is explored. This may result in an inordinate number of access plans to evaluate, as unresolved partial plans may not be pruned effectively.

[0061] As an example, using the approach discussed above, testing revealed it took 28 ms for a 3 table join, 375 ms for a 4 table join, 56, 537 ms for a 5 table join and more than 30 minutes for a 6 table join.

[0062] The present disclosure seeks to improve on the above results, by providing an improved method for selecting an optimal access plan. In particular, the present disclosure provides an improved method for selecting an optimal access plan using a two-phase approach, and an improved method for selecting an optimal access plan using a recursive approach. In both approaches, unresolved partial plans are not developed further (e.g. joined with other plans) until they can be resolved and pruned, thereby limiting the search space for an optimal access plan.

[0063] TWO-PHASE APPROACH

[0064] According to at least some embodiment of the present disclosure, there is provided an improved method for selecting an optimal access plan comprising a two-phase process. In a first phase, join combinations are identified and the resulting cardinalities are estimated, but candidate access plans are not created. In a second phase, plans, including sub-plans with Bloom filters, are created and costed, allowing them to be pruned.

[0065] Reference is now made to FIG. 4, in which a flow chart for the first phase of the two-phase approach method is illustrated.

[0066] The method starts at block 400 and proceeds to block 410 where all pairs of tables to be joined are identified. For example, based on the tables of FIG. 1, and the example query discussed above, the pairs of tables to be joined would include (without considering order) {T1, T2} , {T1, T3} , and {T2, T3} at a first level, and { {T1, T2} , T3. } , { {T1, T3} , T2} , { {T2, T3} , T1} , at a second level.

[0067] The method then proceeds to block 420 where the cardinality of any resulting table from joining the pairs identified at block 410 is estimated. Estimates may be based on statistics, comprising, without limitation, the number of rows in each table, histograms taken on each column, and the number of unique rows in each column.

[0068] The method then proceeds to block 430 to identify Bloom filters candidates. Bloom filter candidates may be defined as a table and a predicate from the query, where the table is selected as the table to which the Bloom filter apply node will be attached. In the present example, the query includes the predicates T1. C1 = T2. C1, T1. C3 = T3. C1, and T2. C2 = T3. C2. This suggests a Bloom filter candidate for table T1, with the predicate T1. C1 = T2. C1, and a Bloom filter candidate for table T1, with the predicate T1. C3 = T3. C1. Similarly, the query suggests a Bloom filter candidate for table T2, with the predicate T1. C1 =T2. C1, and a Bloom filter candidate for table T2, with the predicate T2. C2 = T3. C2. Lastly, the query suggests a Bloom filter candidate for table T3, with the predicate T1. C3 = T3. C1, and a Bloom filter candidate for table T3, with the predicate T2. C2 = T3. C2.

[0069] According to at least some embodiments, heuristics may be used to reduce the number of Bloom filter candidates. For example, for any join pair, only the largest of the two tables may be selected to apply a Bloom filter candidate. Other options are possible.

[0070] The method then proceeds to block 440, where the inner relation combination for each Bloom filter candidate is determined. Specifically, for each Bloom filter candidate, the valid join pairs, from the pairs determined at block 410, are identified.

[0071] Using, from the present example, the Bloom filter candidate for table T1, with the predicate T1. C1 = T2. C1, join pairs with T1 on the outer side and T2 on the inner side are considered. These include T1 JOIN T2, and T1 JOIN {T2, T3} .

[0072] For the Bloom filter candidate for table T1, with the predicate T1. C3 = T3. C1, join pairs with T1 on the outer side and T3 on the inner side are considered. These include T1 JOIN T3, and T1 JOIN {T2, T3} .

[0073] For the Bloom filter candidate for table T2, with the predicate T1. C1 = T2. C1, join pairs with T2 on the outer side and T1 on the inner side are considered. These include T2 JOIN T1, and T2 JOIN {T1, T3} .

[0074] For the Bloom filter candidate for table T2, with the predicate T2. C2 = T3. C2, join pairs with T2 on the outer side and T3 on the inner side are considered. These include T2 JOIN T3, and T2 JOIN {T1, T3} .

[0075] For the Bloom filter candidate for table T3, with the predicate T1. C3 = T3. C1, join pairs with T3 on the outer side and T1 on the inner side are considered. These include T3 JOIN T1, and T3 JOIN {T1, T2} .

[0076] For the Bloom filter candidates for table T3, with the predicate T2. C2 = T3. C2, join pairs with T3 on the outer side and T2 on the inner side are considered. These include T3 JOIN T2, and T3 JOIN {T1, T2} .

[0077] The method then proceeds to block 450, in which Bloom filter (apply) paths are added for each Bloom filter candidate. Specifically, as seen in FIG. 5, sub-plan 501 comprises a T1 scan node, and a Bloom filter apply node with the predicate of T1. C1 = T2. C1, and an associated set of inner relation combinations. Similarly, sub-plans 502, 503, 504, 505, and 506, comprises a scan node, and a Bloom filter apply node with the relevant predicate, and an associated set of inner relation combinations. Each of sub-plans 501, 502, 503, 504, 505, and 506, may also be considered as separate sub-plans for each combination of inner relation. Thus, sub-plan 501 may be understood as comprising a sub-plan 501- {T2} with inner relations of T2, and another sub-plan 501- {T2, T3} with inner relations of {T2, T3} . Throughout this disclosure, these sub-plans may be referred to as [reference numeral] - {inner relations} .

[0078] The method then proceeds to block 460, in which the sub-plans comprising Bloom filter candidates are evaluated. In particular, at block 460, the number of rows resulting from each sub-plan may be estimated, and a cost for applying the Bloom filter may be estimated, based on the associated inner relation combinations.

[0079] The method then ends at block 470.

[0080] Reference is now made to FIG. 6, which illustrates a flow chart of the second phase of the two-phase approach according to at least some embodiments of the present disclosure.

[0081] As seen in FIG. 6, the method starts at block 600 and proceeds to block 610 in which the plan list for every table is created. This step may be performed at the beginning of the second phase, or at some point during the first phase. The plan list for a table includes sub-plans which may produce the table. Some of these sub-plans may include a Bloom filter (apply) node, and different scanning methods such as Sequence Scan or Index Scan.

[0082] The method then proceeds to block 620 for iterating over every join pair, considering their order. In a first instance, block 620 iterates over every join pair of the first level. In the present example, this means iterating over the following join pairs: T1 JOIN T2, T2 JOIN T1, T1 JOIN T3, T3 JOIN T1, T2 JOIN T1, T2 JOIN T3, where the first table is considered the outer table, and the second table is considered the inner table. After iterating over every join pair of the first level, block 620 iterates over every join pair of the second level, and so on until the top level is reached.

[0083] The method then proceeds to block 630 for iterating over every sub-plan in the plan list for the outer table of the current join pair. Based on the present example, assuming the current join pair is T1 JOIN T2, block 630 iterates over every sub-plan in the plan list for table T1. These may include sub-plans 501 and 502 from FIG. 5, and their variations for different scanning methods, as well as sub-plans with no Bloom filter (i.e., just scanning nodes) .

[0084] The method then proceeds to block 640 for iterating over every sub-plan in the plan list for the inner table of the current join pair. Based on the present example, assuming the current join pair is T1 JOIN T2, block 640 iterates over every sub-plan in the plan list for table T2. These may include sub-plans 503 and 504 from FIG. 5, and their variations for different scanning methods, as well as sub-plans with no Bloom filter.

[0085] The method then proceeds to block 650 to determine if the two sub-plans being considered can be joined. When determining if two sub-plans may be joined, the following rules may be applied in at least some embodiments of the present disclosure, when at least one of the two sub-plans comprises a Bloom filter (apply) node:

[0086] · If the inner sub-plan comprises a subset of the inner relation combinations associated to the outer sub-plan, the join mode is ‘hash join’ , and one of the following conditions must be satisfied for the plans to be joined:

[0087] i. The inner sub-plan supplies all of the inner relation combinations associated to the outer sub-plan;

[0088] ii. The inner sub-plan supplies some of the inner relation combinations, and its own inner relation combinations comprise the missing inner relation combinations from the outer sub-plan.

[0089] · If the inner sub-plan does not comprise a subset of the inner relation combinations, and does not comprise a Bloom filter (apply) node, it may be joined to the outer sub-plan.

[0090] These rules are illustrated with respect to FIG. 7A and FIG. 7B.

[0091] Specifically, as seen in FIG. 7A, sub-plan 701 includes a node for scanning table T1, a Bloom filter apply node with the predicate T1. C1 = T2. C1, and inner relation combinations of {T2, T3} . Sub-plan 702 includes a node for scanning table T2, a Bloom filter apply node with the predicate T2. C2 = T3. C2, and inner relation combinations of {T3} .

[0092] Sub-plan 701 may be joined with sub-plan 702, as sub-plan 701’s inner relation combinations include tables T2, and T3, and sub-plan 702 provides table T2, and its inner relation combinations include T3. By joining sub-plan 701 and 702 together, sub-plan 703 is produced. As both branches of sub-plan 703 require to be joined with T3, a valid access plan may be produced by joining sub-plan 703 with a sub-plan which provides T3, as illustrated by access plan 704 illustrated in FIG. 7B.

[0093] Similarly, two plans may be joined if the inner sub-plan provides all the tables of the outer sub-plan’s inner relation combinations, as illustrated in FIG. 8.

[0094] Sub-plan 801 is identical to sub-plan 701, however sub-plan 802 is not identical to sub-plan 702. Specifically, sub-plan 802 includes a scan node for T2, a scan node for T3, a Bloom filter apply node for T2, and a hash join node to join T2 and T3.

[0095] Sub-plans 801 and 802 may be joined as illustrated by access plan 803, because sub-plan 802 provides all the tables specified by sub-plan 801’s inner relation combinations, namely tables T2 and T3.

[0096] FIG. 9 illustrates a scenario where joining two sub-plans is not allowed. Specifically, sub-plan 901 is identical to sub-plans 701 and 801 discussed above, and sub-plan 902 comprises a scan node for table T2, a Bloom filter apply node with the predicate T2. c3 = T4. c4, and inner relation combinations of {T4} . Thus, while sub-plan 902 provides table T2, it’s inner relation combinations do not include T3, which is required for sub-plan 901. As can be seen with sub-plan 903, if sub-plans 901 and 902 were to be joined, the resulting plan would not allow table T1 to join with table T3, as required. Therefore, sub-plan 903 is invalid.

[0097] Returning now to FIG. 6, if the two sub-plans may not be joined, the method iterates through to the next inner sub-plan at block 640. If the two sub-plans can be joined, the method proceeds to block 660, where joined sub-plans are created. In some instances, it may be possible to join sub-plans using different join modes, however, when there is a Bloom filter (apply) node on the outer side, only hash joins are permitted. Bloom filter information, such as inner relation combinations, may be preserved after a join, or discarded if all Bloom filters within the sub-plan are resolved.

[0098] The method then proceeds to block 670, where the sub-plans are costed.

[0099] The method then proceeds to block 680 where the sub-plans created at block 660 are pruned. Specifically, each sub-plan is categorized based on its properties, and only the least expensive sub-plan for each category is kept, while the other sub-plans are pruned. Sub-plans may be categorized based on various factors, including, but not limited to a sort order of the relation, and inner relation combinations.

[0100] The method then proceeds to block 690 where the remaining sub-plans are added to the plan list for the join pair { [outer] , [inner] } , where [inner] and [outer] represent the inner table and the outer table, respectively.

[0101] The method then returns to block 640 to process the next inner sub-plan. Once all inner sub-plans have been processed, the method proceeds back to block 630 to process the next outer sub-plan. Once all outer sub-plans have been processed, the method proceeds back to block 620 to process the next join pair. Once all join pairs are processed, the method ends at block 690, and the join pairs of the second level are processed similarly, using the plan lists created during block 680 of the previous level. This process is repeated until all join pairs of all levels are processed, at which point the created plans are all valid potential access plans.

[0102] Once all valid potential access plans are created, the lowest-cost plan may be selected for execution.

[0103] RECURSIVE APPROACH

[0104] Reference is now made to FIG. 10 which illustrates a method for selecting an access plan using the recursive approach, according to at least some embodiments of the present disclosure.

[0105] For the purposes of simplicity, the method of FIG. 10 will be described assuming that T1 is larger than T2, and T2 is larger than T3.

[0106] The method of FIG. 10 starts at block 1000 and proceeds to block 1001 where Bloom filter candidates are created. Based on the example query, and because T1 is larger than T2, and T2 is larger than T3, the Bloom filter candidates include a Bloom filter candidate for table T1, with the predicate T1. C1 = T2. C1, a Bloom filter candidate for table T1, with the predicate T1. C3 = T3. C1, and a Bloom filter candidate for table T2, with the predicate T2. C2 = T3. C2.

[0107] The method then proceeds to block 1002 where an initial plan list for each table is created. At this stage only scanning nodes are created.

[0108] The method then proceeds to block 1003 for iterating over every join pair, considering their order. In a first instance, block 1003 iterates over every join pair of the first level. In the present example, this means iterating over the following join pairs: T1 JOIN T2, T2 JOIN T1, T1 JOIN T3, T3 JOIN T1, T2 JOIN T1, T2 JOIN T3, and T3 JOIN T2, where the first table is considered the outer table, and the second table is considered the inner table.

[0109] The method then proceeds to block 1004, to determine if any relation of the current join pair comprises a Bloom filter candidate. If there are no Bloom filter candidates, sub-plans for the join pair are created at block 1005, these sub-plans are pruned at block 1006, and the remaining sub-plans are added to the plan list for the current join pair at block 1007.

[0110] If at block 1004, it is found that a relation of the current join pair comprises a Bloom filter candidate, the method proceeds to block 1008 to determine if the Bloom filter candidates may be resolved.

[0111] In the present example, considering the join pair T1 JOIN T2, T1 has Bloom filter candidates, and therefore the method proceeds to block 1008 to determine if all the Bloom filter candidates may be resolved. In this case, table T1 has a Bloom filter candidate which requires table T3 to be resolved, and therefore, the determination of block 1008 is negative. The method therefore proceeds back to block 1003 to process the next join pair. Considering the join pair of T2 JOIN T1, the determination of block 1008 is also negative for the same reasons.

[0112] Considering the next join pair of T1 JOIN T3, at block 1004 it is found that table T1 has Bloom filter candidates, and therefore the method proceeds to block 1008 to determine if all the Bloom filter candidates may be resolved. In this case, table T1 has a Bloom filter candidate which requires table T2 to be resolved, and therefore the determination of block 1008 is negative. The method therefore proceeds back to block 1003 to process the next join pair. Considering the join pair of T3 JOIN T1, the determination of block 1008 is also negative for the same reasons

[0113] Considering the next join pair of T2 JOIN T3, at block 1004 it is found that table T2 has BF candidates, and therefore the method proceeds to block 1008 to determine if the BF candidates may be resolved. In this case, the BF Candidate for table T2 requires table T3, which can be resolved by the inner table of the current join pair, namely T3. Therefore, the determination at block 1008 is positive.

[0114] The method then proceeds to block 1009 where the sub-plans for the outer relation are recursively built, as will be described in detail based on FIG. 11. The method then proceeds to block 1010 where the sub-plans created at block 1009 are joined with sub-plans for the inner relation. The method then proceeds to block 1006 where these sub-plans are pruned, and to block 1007 where the remaining sub-plans are added to the plan list for the current join pair. The method proceeds back to block 1003 to process the next join pair.

[0115] Considering the join pair of T3 JOIN T2, there are no Bloom filter candidates for T3, and therefore the method proceeds to block 1005 to join sub-plans for T3 and T2. The new sub-plans created at block 1005 are then pruned at block 1006 and the remaining sub-plans are added to the plan list for the current join pair at block 1007.

[0116] Reference is now made to FIG. 11, which describes the method performed at block 1009 of the method of FIG. 10. The method of FIG. 10 is performed with parameters, namely a relation and a build list. The build list is the list of relations that are to be joined with the relation. In the example discussed above, the relation is T2, and the build list is {T3} .

[0117] The method of FIG. 11 starts at block 1100 and proceeds to block 1101 to determine if the relation is a leaf node. In this case, the relation is T2 by itself, which is a leaf node, and therefore the method proceeds to block 1102 to iterate over every relation of the build list.

[0118] The method then proceeds to block 1103 to determine if the current relation from the build list resolves the Bloom filter candidate. If not, the method ends. In this case, the build list comprises only T3. As T3 can resolve the Bloom filter candidate, the method proceeds to block 1104, where a Bloom filter apply node is added to the relation sub-plans, and their inner relation combinations are set to the current relation from the build list, namely T3, at block 1105. This produces a sub-plan such as sub-plan 504- {T3} of FIG. 5.

[0119] The method then proceeds to block 1106 where the new sub-plans are pruned and then to block 1107 where the remaining sub-plans are added to the plan list for the relation, which in the current example, is T2. The method then ends. At block 1106, where new sub-plans are pruned based on their cost, their cost may be estimated based on a SEMIJOIN operation.

[0120] Once the method of FIG. 10 is performed at a first level, it is performed for the subsequent level, until all levels have been processed. For the present example, the operation of the method of FIG. 10 at a second level is described below.

[0121] Assuming the first second level join pair to be processed is {T1, T2} JOIN T3, the method proceeds at block 1004 to determine if {T1, T2} comprises Bloom filter candidates. As both tables T1 and T2 are associated to Bloom filter candidates, the method proceeds to block 1008 to determine if all the Bloom filter candidates can be resolved by the outer relation. In this case, the determination is positive because the Bloom filter candidates for T1 require either T2 or T3, and the Bloom filter candidate for T2 requires T3.

[0122] The method then proceeds to block 1009 where sub-plans for the outer relation are recursively created. Specifically, at block 1009, the method of FIG. 11 is invoked with {T1, T2} as the outer relation, and {T3} as the build list.

[0123] Referring now to FIG. 11, at block 1101 it is determined that {T1, T2} is not a leaf node, and the method proceeds to block 1108 to iterate over every ordered join pair that may be used to produce {T1, T2} . As will be appreciated, these join pairs include T1 JOIN T2, and T2 JOIN T1.

[0124] The method then proceeds to block 1109 with the join pair T1 JOIN T2, where the method of FIG. 11 is recursively performed with T2 as the relation and {T3} as the build list. Specifically, at block 1109, the method of FIG. 11 is invoked with the inner relation of the current join pair and the current build list.

[0125] Because T2 is a leaf node, the method proceeds to block 1102 to iterate over every relation of the build list. In this case, the build list only comprises T3. At block 1103, it is determined that T3 resolves the Bloom filter candidate for relation T2, and the method proceeds to block 1104 where Bloom filter apply nodes are created. However, this would create a sub-plan such as sub-plan 504- {T3} of FIG. 5, which was already added to the plan list for T2, and therefore no new sub-plans are created and this instance of the method ends.

[0126] Returning to the method of FIG. 11 with {T1, T2} as the relation, the method proceeds to block 1110, where the method of FIG. 11 is recursively performed with T1 as the relation and {T3, T2, {T3, T2} } as the build list. Specifically, at block 1110, the method of FIG. 11 is invoked with the outer relation of the current join pair, and a build list comprising every element of the current build list (T3 in the present example) , the inner relation of the current join pair (T2 in the present example) , and a union of every element of the current build list and the inner relation of the current join pair ( {T3, T2} , in the present example) .

[0127] Because T1 is a leaf node, the method proceeds to block 1102 to iterate over every relation in the build list. The first relation in the build list is T3, and at block 1103 it is determined whether T3 can resolve Bloom filter candidates for T1. As T1 has a Bloom filter candidate which can be resolved by T3, the method proceeds to block 1104 where a Bloom filter apply node is added to the relation sub-plans, and their inner relation combinations are set to the current relation from the build list, namely T3, at block 1105. This produces a sub-plan such as sub-plan 502- {T3} from FIG. 5.

[0128] The method then proceeds to block 1106 where the new sub-plans are pruned and then to block 1107 where the remaining sub-plans are added to the plan list for the relation, which in the current example, is T1. The method then ends.

[0129] The second relation in the build list is T2, and at block 1103 it is determined that T2 can resolve a Bloom filter candidate for T1. At block 1104, a Bloom filter apply node is added to the relation sub-plans, and their inner relation combinations are set to T2 at block 1105. This produces a sub-plan such as sub-plan 501- {T2} from FIG. 5. The method then proceeds to block 1106 where the new sub-plans are pruned then to block 1107 where the remaining sub-plans are added to the plan list for T1.

[0130] The third relation in the build list is {T2, T3} , and at block 1103 it is determined that {T2, T3} can resolve Bloom filter candidates for T1. At block 1104, a Bloom filter apply node for each resolved Bloom filter candidate is added to sub-plans for T1, and at block 1105, their inner relation combinations are set to {T2, T3} . This produces sub-plans such as the sub-plan illustrated in FIG. 12. The method then proceeds to block 1106 where the new sub-plans are pruned then to block 1107 where the remaining sub-plans are added to the plan list for T1.

[0131] As all relations in the build list have been processed, this level of recursion exits the method of FIG. 11, and we return to the method of FIG. 11 with {T1, T2} as the relation, at block 1111, where the sub-plans from the inner relation’s plan list and the sub-plans created at block 1110 are joined. These new sub-plans are then pruned at block 1106 and added to the plan list for {T1, T2} at block 1107.

[0132] The method then returns to block 1108 to process the next ordered join pair, namely T2 JOIN T1. At block 1109, the method of FIG. 11 is invoked with T1 as the relation and {T3} as a build list. This produces no new sub-plans.

[0133] The method then proceeds to block 1110 where the method of FIG. 11 is invoked with T2 as the relation, and {T3, T1, {T3, T1} } as the build list. This produces a sub-plan such as sub-plan 504- {T1, T3} from FIG. 5.

[0134] The method then proceeds to block 1111 where the new sub-plans created at block 1110 are joined to the sub-plans from the plan list for T1. The sub-plans created at block 1111 are then pruned at block 1106 and added to the plan list for {T1, T2} at block 1107. This level of recursion ends, and we return to the method of FIG. 10, at block 1010.

[0135] At block 1010, the sub-plans created for {T1, T2} at block 1009 are joined with the sub-plans for T3. The method then proceeds to block 1006 where these new sub-plans are pruned, and the remaining sub-plans are added to the plan list for {T1, T2, T3} at block 1007.

[0136] The above describes the operation of the method of FIG. 10 for the join pair of {T1, T2} JOIN T3. This method is then repeated for the other join pairs of T3 JOIN {T1, T2} , {T1, T3} JOIN T2, T2 JOIN {T1, T3} , {T2, T3} JOIN T1, and T1 JOIN {T2, T3} . After each join pair of this level have been processed, the plan list for {T1, T2, T3} comprises a plurality of complete access plans, and the optimal access plan may be selected and executed. As will be appreciated, if more tables were involved in the query, more levels would be needed to achieve complete access plans.

[0137] As seen from the above, using the recursive approach, sub-plans with Bloom filter candidates are not used as the basis for further sub-plans unless they may be resolved by being joined with another sub-plan.

[0138] The above functionality may be implemented on any one or combination of computing devices. FIG. 13 is a block diagram of a computing device 1300 that may be used for implementing the devices and methods disclosed herein. Specific devices may utilize all of the components shown, or only a subset of the components, and levels of integration may vary from device to device. Furthermore, a device may contain multiple instances of a component, such as multiple processing units, processors, memories, transmitters, receivers, etc. The computing device 1300 may comprise a processor 1310, memory 1320, a mass storage device 1340, and peripherals 1330. Peripherals 1330 may comprise, amongst others one or more input / output devices, such as a speaker, microphone, mouse, touchscreen, keypad, keyboard, printer, display, network interfaces, and the like. Communications between processor 1310, memory 1320, mass storage device 1340, and peripherals 1330 may occur through one or more buses 1350.

[0139] The bus 1350 may be one or more of any type of several bus architectures including a memory bus or memory controller, a peripheral bus, video bus, or the like. The processor 1310 may comprise any type of electronic data processor. The memory 1320 may comprise any type of system memory such as static random-access memory (SRAM) , dynamic random-access memory (DRAM) , synchronous DRAM (SDRAM) , read-only memory (ROM) , a combination thereof, or the like. In an embodiment, the memory 1320 may include ROM for use at boot-up, and DRAM for program and data storage for use while executing programs.

[0140] The mass storage device 1340 may comprise any type of storage device configured to store data, programs (e.g. instructions or code) , and other information and to make the data, programs, and other information accessible via the bus. The mass storage device 1340 may comprise, for example, one or more of a solid-state drive, hard disk drive, a magnetic disk drive, an optical disk drive, or the like. The memory 1320 or mass storage 1340 may store instructions, which when executed by a processor or processing unit, cause or configure the computing device 1300 to perform any of the methods described herein.

[0141] Computing device 1300 may further comprise a communications subsystem 1360 for communicating with other computing devices or for connecting computing device 1300 to a computer network. Communications subsystem 1360 may  comprise one or more network interfaces (not shown) , which may comprise wired links, such as an Ethernet cable or the like, and / or wireless links to access nodes or different networks. The network interface allows the processing unit to communicate with remote units via the networks. For example, the network interface may provide wireless communication via one or more transmitters / transmit antennas 1370 and one or more receivers / receive antennas 1370. In an embodiment, the processing unit is coupled to a local-area network or a wide-area network, for data processing and communications with remote devices, such as other processing units, the Internet, remote storage facilities, or the like.

[0142] Computing device may further comprise a power source 1380.

[0143] The present disclosure may be implemented on a computing device such as exemplary computing device 1300. Computing device 1300 may be a network element of a telecommunications network, such that the network element may be connected to other network elements of the telecommunication network, where all network elements form the telecommunication network. The network element may also receive communications from client devices connected to the telecommunication network and provide services to such client devices.

[0144] Through the descriptions of the preceding embodiments, the teachings of the present disclosure may be implemented by using hardware only or by using a combination of software and hardware. Software or other computer executable instructions for implementing one or more embodiments, or one or more portions thereof, may be stored on any suitable computer readable storage medium. The computer readable storage medium may be a tangible or in transitory / non-transitory medium such as optical (e.g., CD, DVD, Blu-Ray, etc. ) , magnetic, hard disk, volatile or non-volatile, solid state, or any other type of storage medium known in the art.

[0145] Additional features and advantages of the present disclosure will be appreciated by those skilled in the art.

[0146] The structure, features, accessories, and alternatives of specific embodiments described herein and shown in the Figures are intended to apply generally to all of the teachings of the present disclosure, including to all of the embodiments described and illustrated herein, insofar as they are compatible. In other words, the structure, features, accessories, and alternatives of a specific embodiment are not intended to be limited to only that specific embodiment unless so indicated.

[0147] Moreover, the previous detailed description is provided to enable any person skilled in the art to make or use one or more embodiments according to the present disclosure. Various modifications to those embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the teachings provided herein. Thus, the present methods, systems, and or devices are not intended to be limited to the embodiments disclosed herein. The scope of the claims should not be limited by these embodiments, but should be given the broadest interpretation consistent with the description as a whole. Reference to an element in the singular, such as by use of the article "a" or "an" is not intended to mean "one and only one" unless specifically so stated, but rather "one or more" . All structural and functional equivalents to the elements of the various embodiments described throughout the disclosure that are known or later come to be known to those of ordinary skill in the art are intended to be encompassed by the elements of the claims.

[0148] Furthermore, nothing herein is intended as an admission of prior art or of common general knowledge. Furthermore, citation or identification of any document in this application is not an admission that such document is available as prior art, or that any reference forms a part of the common general knowledge in the art. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.

[0149] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.

Claims

1.A method for selecting an access plan, comprising:a) receiving a query, the query comprising at least one predicate related to at least two tables;b) selecting Bloom filter candidates applying to at least one of the at least two tables;c) determining, for each Bloom filter candidate, a set of required inner tables;d) building a plurality of sub-plans for each of the at least two tables;e) selecting an outer sub-plan and an inner sub-plan from the plurality of sub-plans;when the outer sub-plan comprises a Bloom filter candidate:f) determining if the outer sub-plan and the inner sub-plan can be joined; andg) upon determining that the outer sub-plan and the inner sub-plan can be joined, joining the outer sub-plan with the inner sub-plan to create a new sub-plan.2.The method of claim 1, wherein determining if the outer sub-plan and the inner sub-plan can be joined comprises:determining that the inner sub-plan can resolve the Bloom filter candidate of the outer sub-plan.3.The method of claim 1, wherein determining if the outer sub-plan and the inner sub-plan can be joined comprises:determining that the inner sub-plan produces a first set of inner tables;determining that the inner sub-plan requires a second set of inner tables; anddetermining that a combined set of the first set of inner tables and the second set of inner tables matches a set of inner tables required by the outer sub-plan.4.The method of claim 1, wherein joining the outer sub-plan with the inner sub-plan uses a hash join.5.The method of claim 1, further comprising:h) evaluating a cost for the new sub-plan based on a semi-join operation between the outer sub-plan and the inner sub-plan.6.The method of claim 5, further comprising:repeating steps e) , f) , g) , and h) for different sub-plans from the plurality of sub-plans to create a plurality of new sub-plans.7.The method of claim 6, further comprising:repeating steps d) , e) , f) , and g) with sub-plans from the plurality of new sub-plans, until the new sub-plans comprise at least one complete access plan.8.The method of claim 7, further comprising:selecting the access plan based on the cost of each of the at least one complete access plan; andexecuting the access plan.9.The method of claim 1, wherein step c) comprises:building a sequence scan node for each of the at least one table; andbuilding an index scan node for each of the at least one table.10.The method of claim 1, wherein if the outer plan does not comprise a Bloom filter candidate:joining the outer sub-plan with the inner sub-plan with at least one of a hash join, a merge join, and a nest-loop join.11.The method of claim 1, further comprising, adding a Bloom filter apply node to sub-plans with Bloom filter candidates.12.The method of claim 11, wherein step g) further comprises:adding a Bloom filter build node to the inner sub-plan.13.The method of claim 5, further comprising pruning the new sub-plan when the cost for the new sub-plan exceeds a cost of equivalent sub-plans.14.A computing device comprising:a processor; andmemory:wherein the computing device is configured to perform the method of any one of claims 1 to 13.15.A computer-readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions for performing the method of any one of claims 1 to 13.16.A method for selecting an access plan, comprising:a) receiving a query, the query comprising at least one predicate related to at least two tables;b) selecting Bloom filter candidates applying to at least one of the at least two tables;c) determining, for each Bloom filter candidate, a set of required inner tables;d) creating sub-plans for scanning each of the at least two tables;e) joining sub-plans without tables that are Bloom filter candidates;f) recursively processing sub-plans with tables that are Bloom filter candidates, wherein said recursive processing comprises:when a given sub-plan is a leaf node,i) joining the given sub-plan with other sub-plans when the Bloom filter is resolved by the other sub-plans to create a first set of new sub-plans; andii) evaluating a cost of each of the first set of new sub-plans;otherwise,iii) recursively processing an inner sub-plan and an outer sub-plan of the given sub-plan to create a second set of new sub-plans;iv) joining sub-plans from the second set of the new sub-plans to create a third set of new sub-plans; andv) evaluating a cost of each of the third set of new sub-plans.17.The method of claim 16, further comprising:repeating step e) and f) until at least one complete access plan is created.18.The method of claim 17, further comprising:selecting the access plan based on the cost of each of the at least one complete access plan; andexecuting the access plan.19.The method of claim 16, wherein step i) uses a hash join.20.The method of claim 16, wherein step ii) evaluates the cost based on a semi-join operation of the given sub-plan with a selected sub-plan of the other sub-plans.21.The method of claim 20, further comprising pruning sub-plans from the first set of new sub-plans.22.The method of claim 16, further comprising pruning sub-plans from the third-set of new sub-plans.23.The method of claim 16, wherein selecting Bloom filter candidates comprises selecting a largest table from a predicate of the at least one predicate.24.A computing device comprising:a processor; andmemory:wherein the computing device is configured to perform the method of any one of claims 16 to 23.25.A computer-readable medium having stored thereon executable code for execution by a processor of a computing device, the executable code comprising instructions for performing the method of any one of claims 16 to 23.

Images