Examples of Physical Query Plan Alternatives. Selected Material from Chapters 12, 14 and 15

Transcription

1 Examples of Physical Query Plan Alternatives Selected Material from Chapters 12, 14 and 15 1

2 Query Optimization NOTE: SQL provides many ways to express a query. HENCE: System has many options for evaluating a query. Optimizer is important for query performance: Generates alternative plans Chooses plan with least estimated cost. Ideally, find best plan. Realistically, consistently find a quite good one. 2

3 A Query Evaluation Plan An extended relational algebra tree Annotations at each node indicate: access methods to use for each table. implementation methods used for each relational operator. 3

4 A Query Evaluation Plan bid=100 rating > 5 bid=100 rating > 5 (Simple Nested Loops) 4

5 Query Optimization Multi-operator Queries: Pipelined Evaluation On-the-fly: The result of one operator is pipelined to another operator without creating a temporary table to hold intermediate result, called on-the-fly. Materialized : Otherwise, intermediate results must be materialized before the next operator can access it. C A B 5

6 Alternative Plans: Schema Examples (sid: integer, bid: integer, day: dates, rname: string) (sid: integer, : string, rating: integer, age: real) : Each tuple is 40 bytes long, 100 tuples per page, 1000 pages. : Each tuple is 50 bytes long, 80 tuples per page, 500 pages. 6

7 Alternative Plans: Motivating Example RA Tree: SELECT S. FROM R, S WHERE R.sid=S.sid AND R.bid=100 AND S.rating>5 bid=100 rating > 5 7

8 SELECT S. FROM R, S WHERE R.sid=S.sid AND R.bid=100 AND S.rating>5 RA Tree: bid=100 rating > 5 Costs : 1. Scan : For each page of, scan *1000 I/Os Or, 2. Scan For each page of, scan * 500 I/Os bid=100 rating > 5 (Simple Nested Loops) Plan: 8

9 Alternative Plans: Motivating Example Cost: *1000 I/Os Typically, bad plan! Reasons : selections could be `pushed earlier, no use made of indexes Goal of optimization: Find more efficient plan SELECT S. FROM R, S WHERE R.sid=S.sid AND R.bid=100 AND S.rating>5 Plan: bid=100 rating > 5 (Simple Nested Loops) 9

10 Alternative Plans No Indexes Main idea : push selects down. bid=100 rating > 5 10

11 Alternative Plans No Indexes Main idea : push selects down. (Sort-Merge Join) (Scan; (Scan; write to temp T1) bid=100 rating > 5 write to temp T2) 11

12 Alternative Plan - 2 With 5 buffer pages, cost of plan: Scan (1000) + write temp T1 (if we have 100 boats, uniform distribution then it is : 10 pages,). Scan (500) + write temp T2 ( if we have 10 ratings then it is : 250 pages). (Scan; write to temp T1) Sort T1 (2*2*10), sort T2 (2*4*250), merge (10+250) Total: 4060 page I/Os. bid=100 (Sort-Merge Join rating > 5 (Scan; write to temp T2) 12

13 Alternative Plans - 2 With 5 buffer pages, Scanning and filtering: IOs temp T1 (Scan; write to temp T1) bid=100 (Sort-Merge Join) temp T2 rating > 5 (Scan; write to temp T2) Optimization1: block nested loops join: join cost = 10+4*250, total cost = Optimization2: `push projections: T1 only sid, 10/4=[2.5]=3;T1 fits in 3 pages, T2 only sid and, 250/2=125 pages cost of BNL drops to 125 IOs, Total cost < 2000 IOs 13

14 Alternative Plan : Using Indices? Push Selections Down? What Indices help here? Index on.bid? Index on.rating? Index on.sid? bid=100 rating > 5 Index on.sid? 14

15 Example Plan : With Index With index on.bid : Assume 100 bid values. Assume 100,000 tuples. Assume 100 tuples/disk We get 100,000/100 = 1000 tuples On 1000/100 = 10 disk pages. If index clustered, Cost = 10 I/Os. (Use hash index; do not write result to temp) rating > 5 bid=100 15

16 Example Plan : With Index With index on.bid : Assume 100 bid values. Assume 100,000 tuples. Assume 100 tuples/disk We get 100,000/100 = 1000 tuples On 1000/100 = 10 disk pages. If index clustered, Cost = 10 I/Os. (Use hash index; do not write result to temp) rating > 5 bid=100 16

17 Example Plan : Use Another Index Index on? Which? Selection on may reduce number of tuples considered in join. rating > 5 (Index Nested Loop Join, with pipelining ) But then requires us to materialize the Sailor tuples again (Use hash index; do not write result to temp) bid=100? 17

18 Index Nested Loop with Pipelining: Outer is not materialized Projecting out rating > 5 unnecessary fields from (Index Nested Loops, with pipelining ) outer doesn t help (Use hash index; do bid=100 not write result to temp) 18

19 Example Plan Continued Index on.sid : sid is key for. At most one matching tuple, unclustered on sid is OK. rating > 5 Cost? - For each tuples (1000): - get matching tuple (1.2 I/O). - So total IOs. bid=100 (Index Nested Loops, with pipelining ) 19

20 Alternative Plan : With Second Index Selection Push down? Push (rating>5) before join? Answer: rating > 5 - No, because of availability of sid index on. (Index Nested Loops, with pipelining ) Reason : -No index on selection result. (Use hash index; do not write result to temp) bid=100 - Then lookup requires scan. 20

21 Summary A query is evaluated by converting it to a tree of operators and evaluating the operators in the tree. There are alternative evaluation algorithms for each relational operator. Query evaluation must compare alternative plans based on their estimated costs Must understand query optimization to understand performance impact of a given database design on a query workload 21