Database System Implementation CSE 507 Query Processing and Query Optimization Slides adapted from Silberschatz, Korth and Sudarshan Database System Concepts – 6th Edition. And Elamsri and Navathe, Fundamentals of Database Systems – 6th Edition.

Basic Steps in Query Processing Parsing and translation Optimization Evaluation

Query Optimization: Introduction Alternative ways of evaluating a given query Equivalent expressions Different algorithms for each operation Which execution plan is most likely to be more efficient? --- Your best intuition

Query Optimization: Introduction An evaluation plan defines exactly what algorithm is used for each operation, and how the execution of the operations is coordinated.

Query Optimization: Introduction Cost difference between evaluation plans for a query can be enormous E.g. seconds vs. days in some cases. Estimation of plan cost typically uses: Statistical information about relations. Statistics estimation for intermediate results Cost formulae for algorithms, computed using statistics, etc….

Query Optimization: Introduction Steps in an ideal cost-based query optimizer: Generate logically equivalent expressions using equivalence rules. Annotate resultant expressions to get alternative query plans. Choose the cheapest plan based on estimated cost.

Generating Equivalent Expressions

Transforming Relational Expressions Two relational algebra expressions are said to be equivalent if the two expressions generate the same set of tuples on every legal database instance Note: order of tuples is irrelevant An equivalence rule says that expressions of two forms are equivalent Can replace expression of first form by second, or vice versa

Equivalence Rules 2. Selection operations are commutative. 1. Conjunctive selection operations can be deconstructed into a sequence of individual selections. 2. Selection operations are commutative. 3. Only the last in a sequence of projection operations is needed, the others can be omitted. Selections can be combined with Cartesian products and theta joins. (E1 X E2) = E1  E2 1(E1 2 E2) = E1 1 2 E2

Equivalence Rules 5. Theta-join operations (and natural joins) are commutative. E1  E2 = E2  E1 6. (a) Natural join operations are associative: (E1 E2) E3 = E1 (E2 E3) (b) Theta joins are associative in the following manner: (E1 1 E2) 2 3 E3 = E1 1 3 (E2 2 E3) where 2 involves attributes from only E2 and E3.

Pictorial Depiction of Equivalence Rules

Equivalence Rules 7. The selection operation distributes over the theta join operation under the following two conditions: (a) When all the attributes in 0 involve only the attributes of one of the expressions (E1) being joined. 0E1  E2) = (0(E1))  E2 (b) When  1 involves only the attributes of E1 and 2 involves only the attributes of E2. 1 E1  E2) = (1(E1))  ( (E2))

Equivalence Rules

Examples of Equivalence Rules: Selection Query: Assume the following query: customer_name(branch_city = “NewDelhi”(branch (account depositor))) Transformation using rule 7a. customer_name ((branch_city =“NewDelhi”(branch)) (account depositor)) Performing the selection as early as possible reduces the size of the relation to be joined!

Examples of Equivalence Rules: Projection customer_name((branch_city = “NewDelhi” (branch account)) depositor) When we compute (branch_city = “NewDelhi” (branch account ) we obtain a relation whose schema can have attributes like branch_name branch_city Account Type (only this may be used in next join) account_number Balance, etc.

Examples of Equivalence Rules: Projection Push projections using equivalence rules 8a and 8b; Eliminate unneeded attributes from intermediate results to get: customer_name (( account_number ((branch_city = “NewDelhi” (branch account )) depositor ) Performing the projection as early as possible reduces the size of the relation to be joined.

Examples of Equivalence Rules: Join Ordering For all relations r1, r2, and r3, (r1 r2) r3 = r1 (r2 r3 ) (Join Associativity) If r2 r3 is quite large and r1 r2 is small, we choose (r1 r2) r3 so that we compute and store a smaller temporary relation.

Examples of Equivalence Rules: Join Ordering customer_name((branch_city = “New Delhi”(branch)) (account depositor) Could compute the join between account and depositor first, and join result with branch. Join between account and depositor is likely to be a large relation. Only a small fraction of the bank’s customers are likely to have accounts in branches located in Delhi. It is better to compute branch_city = “NewDelhi” (branch) account first.

Annotate resulting expressions to get execution plans: An example

Choosing the Best Execution Plan

Choosing the Best Execution Plan Must consider the interaction of evaluation techniques choosing the cheapest algorithm for each operation independently may not yield best overall algorithm. E.g. merge-join may be costlier than hash-join, but may provide a sorted output which reduces the cost for an outer level aggregation.

Choosing the Best Execution Plan Practical query optimizers incorporate elements of the following two broad approaches: 1. Search all the plans and choose the best plan in a cost-based fashion. 2. Uses heuristics to choose a plan.

Cost based Optimization Practical query optimizers incorporate elements of the following two broad approaches: 1. Search all the plans and choose the best plan in a cost-based fashion (very costly) 2. Uses heuristics to choose a plan.

Heuristic Based Optimization Cost-based optimization is expensive, even with dynamic programming. but worthwhile for frequently used queries on large datasets Systems may use heuristics to reduce the number of choices that must be made in a cost-based fashion. Heuristic optimization transforms the query-tree by using a set of rules that typically (but not in all cases) improve execution performance:

Heuristic Based Optimization (Refer Navathe book) Break up any select operations with conjunctive conditions into a cascade of select operations. Move each select operation as far down the query tree as is permitted by the attributes involved in the select condition. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. If possible execute smaller joins first. Combine a Cartesian product operation with a subsequent select operation in the tree into a join operation. Break down and move lists of projection attributes down the tree as far as possible by creating new project operations as needed. Identify subtrees that represent groups of operations that can be executed by a single algorithm.

Heuristic Based Optimization Example SELECT LNAME FROM EMPLOYEE, WORKS_ON, PROJECT WHERE PType = ‘Chem’ AND PNMUBER=PNO AND ESSN=SSN AND BDATE > ‘1957-12-31’; Lname Ptype = “Chem” And Pnumber = Pno And Essn=SSn And Bdate>1957-12-31 PROJECT EMPLOYEE WORKS_ON

Heuristic Based Optimization Example Break up any select operations with conjunctive conditions into a cascade of select operations. Move each select operation as far down the query tree as is permitted by the attributes involved in the select condition. Lname  Ptype = “Chem” And Pnumber = Pno And Essn=SSn And Bdate>1957-12-31 PROJECT EMPLOYEE WORKS_ON

Heuristic Based Optimization Example Break up any select operations with conjunctive conditions into a cascade of select operations. Move each select operation as far down the query tree as is permitted by the attributes involved in the select condition. Lname  Ptype = “Chem” ( Pnumber = Pno ( Essn=SSn ( Bdate>1957-12-31))) PROJECT EMPLOYEE WORKS_ON

Heuristic Based Optimization Example Break up any select operations with conjunctive conditions into a cascade of select operations. Move each select operation as far down the query tree as is permitted by the attributes involved in the select condition. Lname  Ptype = “Chem” ( Pnumber = Pno ( Essn=SSn ( Bdate>1957-12-31))) PROJECT EMPLOYEE WORKS_ON

Heuristic Based Optimization Example Break up any select operations with conjunctive conditions into a cascade of select operations. Move each select operation as far down the query tree as is permitted by the attributes involved in the select condition. Lname  Ptype = “Chem” ( Pnumber = Pno ( Essn=SSn ( Bdate>1957-12-31))) PROJECT EMPLOYEE WORKS_ON

Heuristic Based Optimization Example Break up any select operations with conjunctive conditions into a cascade of select operations. Move each select operation as far down the query tree as is permitted by the attributes involved in the select condition. Lname ( Pnumber = Pno ( Essn=SSn ))  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example Break up any select operations with conjunctive conditions into a cascade of select operations. Move each select operation as far down the query tree as is permitted by the attributes involved in the select condition. Lname  Pnumber = Pno  Essn=SSn  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Lname  Pnumber = Pno  Essn=SSn  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Which are the most restrictive selection conditions? Lname  Pnumber = Pno  Essn=SSn  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Which are the most restrictive selection conditions? Lname  Pnumber = Pno  Essn=SSn 1st ?  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Which are the most restrictive selection conditions? Lname  Pnumber = Pno  Essn=SSn 2nd ? 1st ?  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Which are the most restrictive selection conditions? Lname  Pnumber = Pno 3rd ?  Essn=SSn 2nd ? 1st ?  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Which are the most restrictive selection conditions? Lname 4th ?  Pnumber = Pno 3rd ?  Essn=SSn 2nd ? 1st ?  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Can we bring 1st and 2nd together if they are the most selective conditions? Lname 4th ?  Pnumber = Pno 3rd ?  Essn=SSn 2nd ? 1st ?  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Cannot bring 1st and 2nd together as they will create a cross product Lname 4th ?  Pnumber = Pno 3rd ?  Essn=SSn 2nd ? 1st ?  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Also rearrange the joins to execute small first Lname Any other shuffling possible? 4th ?  Pnumber = Pno 3rd ?  Essn=SSn 2nd ? 1st ?  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Also rearrange the joins to execute small first Assume the following: #rec in Employee = 1 Lakh #rec in Works_On = 2 Lakh; assume each emp works on exactly 2 projects. (no sharing) #rec in Project = 2 Lakh Lname  Pnumber = Pno  Essn=SSn  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Also rearrange the joins to execute small first Further assume the following #rec from Employee after selection condition = 50000 #rec Project after selection condition = 10 Lname  Pnumber = Pno  Essn=SSn  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Also rearrange the joins to execute small first Therefore: #rec after Emp join Works_on = 1 Lakh #rec after Project join Works_on = 10 In other words, result of Project join Works_on would be smaller and therefore should be done first. This way smaller intermediate result table would be written and read back. Lname  Pnumber = Pno  Essn=SSn  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Also rearrange the joins to execute small first Lname 4th Shuffling the joins conditions  Pnumber = Pno 3rd  Essn=SSn  Ptype = “Chem”  Bdate>1957-12-31 WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 3. Rearrange the leaf nodes of the tree so that the leaf node relations with the most restrictive select operations are executed first in the query tree representation. Also rearrange the joins to execute small first. Lname Shuffling the joins conditions  Essn=SSn  Pnumber = Pno  Bdate>1957-12-31  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 4. Combine a Cartesian product operation with a subsequent select operation in the tree into a join operation. Lname  Essn=SSn  Pnumber = Pno  Bdate>1957-12-31  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 4. Combine a Cartesian product operation with a subsequent select operation in the tree into a join operation. Lname  Essn=SSn  Pnumber = Pno  Bdate>1957-12-31  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 5. Break down and move lists of projection attributes down the tree as far as possible by creating new project operations as needed. Any Ideas? Btw Lname is an attribute of the Employee table only. Lname  Essn=SSn  Pnumber = Pno  Bdate>1957-12-31  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 5. Break down and move lists of projection attributes down the tree as far as possible by creating new project operations as needed. Key Tactic: (a) Move Lname towards to Employee. (b) For others keep what is bare min required. Lname  Essn=SSn  Pnumber = Pno  Bdate>1957-12-31  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

Heuristic Based Optimization Example 5. Break down and move lists of projection attributes down the tree as far as possible by creating new project operations as needed. Key Tactic: (a) Move Lname towards to Employee. (b) For others keep what is bare min required. Lname  Essn=SSn Essn  Pnumber = Pno Lname, Ssn Pnumber  Bdate>1957-12-31 Essn, Pno  Ptype = “Chem” EMPLOYEE WORKS_ON PROJECT

Cost based Optimization: Example on Join ordering Consider finding the best join-order for r1 r2 . . . rn. There are (2(n – 1))!/(n – 1)! different join orders for above expression. No need to generate all the join orders. Using dynamic programming, the least-cost join order for any subset of {r1, r2, . . . rn} is computed only once and stored for future use.

Cost based Optimization: Example on Join ordering To find best join tree for a set of n relations: To find best plan for a set S of n relations, consider all possible plans of the form: S1 (S – S1) where S1 is any non-empty subset of S. Recursively compute costs for joining subsets of S to find the cost of each plan. Choose the cheapest of the 2n – 1 alternatives. Store and reuse the cost of common sub-expressions.

Cost based Optimization: Join ordering algorithm procedure findbestplan(S) if (bestplan[S].cost  ) return bestplan[S] // else bestplan[S] has not been computed earlier, compute it now if (S contains only 1 relation) set bestplan[S].plan and bestplan[S].cost based on the best way of accessing S /* Using selections on S and indices on S */ else for each non-empty subset S1 of S such that S1  S P1= findbestplan(S1) P2= findbestplan(S - S1) A = best algorithm for joining results of P1 and P2 cost = P1.cost + P2.cost + cost of A if cost < bestplan[S].cost bestplan[S].cost = cost bestplan[S].plan = “execute P1.plan; execute P2.plan; join results of P1 and P2 using A” return bestplan[S]

Cost based Optimization: Join ordering algorithm Preferred by most query optimizers