Presentation is loading. Please wait.

Presentation is loading. Please wait.

Database System Implementation CSE 507

Similar presentations


Presentation on theme: "Database System Implementation CSE 507"— Presentation transcript:

1 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.

2 Basic Steps in Query Processing
Parsing and translation Optimization Evaluation

3 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

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

5 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….

6 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.

7 Generating Equivalent Expressions

8 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

9 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

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

11 Pictorial Depiction of Equivalence Rules

12 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))

13 Equivalence Rules

14 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!

15 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.

16 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.

17 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.

18 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.

19 Annotate resulting expressions to get execution plans: An example

20 Choosing the Best Execution Plan

21 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.

22 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.

23 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.

24 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:

25 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.

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

27 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> PROJECT EMPLOYEE WORKS_ON

28 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> ))) PROJECT EMPLOYEE WORKS_ON

29 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> ))) PROJECT EMPLOYEE WORKS_ON

30 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> ))) PROJECT EMPLOYEE WORKS_ON

31 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> WORKS_ON EMPLOYEE PROJECT

32 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> WORKS_ON EMPLOYEE PROJECT

33 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> WORKS_ON EMPLOYEE PROJECT

34 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> WORKS_ON EMPLOYEE PROJECT

35 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> WORKS_ON EMPLOYEE PROJECT

36 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> WORKS_ON EMPLOYEE PROJECT

37 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> WORKS_ON EMPLOYEE PROJECT

38 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> WORKS_ON EMPLOYEE PROJECT

39 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> WORKS_ON EMPLOYEE PROJECT

40 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> WORKS_ON EMPLOYEE PROJECT

41 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> WORKS_ON EMPLOYEE PROJECT

42 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> WORKS_ON EMPLOYEE PROJECT

43 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> WORKS_ON EMPLOYEE PROJECT

44 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> WORKS_ON EMPLOYEE PROJECT

45 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> WORKS_ON EMPLOYEE PROJECT

46 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>  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

47 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>  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

48 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>  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

49 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>  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

50 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>  Ptype = “Chem” WORKS_ON EMPLOYEE PROJECT

51 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> Essn, Pno  Ptype = “Chem” EMPLOYEE WORKS_ON PROJECT

52 Cost based Optimization: Example on Join ordering
Consider finding the best join-order for r1 r 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.

53 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.

54 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]

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


Download ppt "Database System Implementation CSE 507"

Similar presentations


Ads by Google