PASS Summit 2010 Keynote David DeWitt

SQL Query Optimization: Why Is It So Hard To Get Right? David J. DeWitt Microsoft Jim Gray Systems Lab Madison, Wisconsin dewitt@microsoft.com © 2010 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied in this presentation.

A Third Keynote? 2

A Third Keynote? Got to show off Got to tell you about the PDW Appliance How can I SQL 11 Possibly The “Impress Index” 1 IMPRESS YOU? 2 My boss’s boss My boss Me 3 Cool! Awesome! Day 1 Day 2 Day 3 (Ted Kummert) (Quentin Clark) (David DeWitt)

How About a Quiz to Start! • Who painted this picture? o Mondrian? o Picasso? o Ingres? • Actually it was the SQL P1 Server query optimizer!! P2 o Plan space for TPC-H query 8 as the parameter values for Acct-Bal and ExtendedPrice are varied P3 P4 S eS rQvL e r o Each color represents a different query plan o Yikes! 4

Who Is This Guy Again? DeWitt • Spent 32 years as a computer science professor at the University of Wisconsin • Joined Microsoft in March 2008 o Runs the Jim Gray Systems Lab in Madison, WI o Lab is closely affiliated with the DB group at University of Wisconsin • 3 faculty and 8 graduate students working on projects o Built analytics and semijoin components of PDW V1. Currently working on a number of features for PDW V2

Today … I am going to talk about SQL query optimization  You voted for this topic on the PASS web site  Don’t blame me if you didn’t vote and wanted to hear about map-reduce and no-sql database systems instead Starting with the fundamental principals Map-Reduce Query Optimization My hope is that you will leave understanding why all database systems sometimes produce really bad plans

Anonymous Quote 7

The Role of the Query Optimizer (100,000 ft view) SQL Magic Awesome Statement Happens Query Plan Query Optimizer

What’s the Magic? Consider Query 8 of the TPC-H benchmark: Select o_year, sum(case A very big haystack to when nation = 'BRAZIL' then searching through be volume else 0 end) / sum(volume) from ( Should not take hours select YEAR(O_ORDERDATE) as o_year, L_EXTENDEDPRICE * a plan! or days to pick (1 - L_DISCOUNT) as volume, n2.N_NAME as nation … from PART, SUPPLIER, LINEITEM, ORDERS, CUSTOMER, NATION n1, There about 22 million NATION n2, REGION where alternative ways of executing P_PARTKEY = L_PARTKEY and S_SUPPKEY = L_SUPPKEY and L_ORDERKEY = O_ORDERKEY and O_CUSTKEY = C_CUSTKEY this query! and C_NATIONKEY = n1.N_NATIONKEY and n1.N_REGIONKEY = R_REGIONKEY and R_NAME = 'AMERICA„ and S_NATIONKEY = n2.N_NATIONKEY and O_ORDERDATE between '1995-01-01' and '1996-12-31' and P_TYPE = 'ECONOMY ANODIZED STEEL' The QO must select a plan that and S_ACCTBAL <= constant-1 and L_EXTENDEDPRICE <= constant-2 runs in seconds or minutes, not ) as all_nations days or weeks! group by o_year order by o_year Plan 1 Plan 2 Plan 3 Plan 4 Plan 5

Some Historical Background • Cost-based query optimization was invented by Pat Selinger as part of the IBM System R project in the late 1970s (System R became DB2) • Remains the hardest part of building a DBMS 30+ years later o Progress is hindered by fear of regressions o Far too frequently the QO picks an inefficient plan • Situation further complicated by advances in hardware and the rest of the Huge! DBMS software 10X o Hardware is 1000X bigger and faster Queries o DB software is 10X faster 1000X Software o Queries over huge amounts of data are possible IF Hardware the QO picks the right plan 10

More Precisely: The Role of the Query Optimizer Transform SQL queries into an efficient execution plan Database System Query Query Execution SQL Query Parser Optimizer Engine Logical Physical operator tree operator tree Logical operators: what they do Physical operators: how they do it e.g., union, selection, project, e.g., nested loop join, sort-merge join, grouping join, hash join, index join 11

Reviews A First Example Date CID MID Rating … … … … SELECT Query Average(Rating) Query Parser Execution FROM Reviews Optimizer Engine WHERE MID = 932 Avg (Rating) or Avg_agg Avg_agg [Cnt, Sum] [Cnt, Sum] Select Index Lookup MID = 932 Filter MID = 932 MID = 932 Reviews Scan MID Index Logical operator tree Reviews Reviews Query Plan #1 Query Plan #2 12

Query Plan #1 • Plan starts by scanning the entire Avg_agg [Cnt, Sum] Reviews table o # of disk I/Os will be equal to the # of pages in the Reviews table Filter o I/Os will be sequential. Each I/O will require MID = 932 about 0.1 milliseconds (0.0001 seconds) • Filter predicate “MID = 932” is Scan applied to all rows • Only rows that satisfy the Reviews predicate are passed on to the average computation 13

Query Plan #2 Avg_agg [Cnt, Sum] • MID index is used to retrieve only those rows whose MID field Index Lookup (attribute) is equal to 932 MID = 932 o Since index is not “clustered”, about one disk I/O will be performed for each row MID o Each disk I/O will require a random seek Index and will take about 3 milliseconds (ms) • Retrieved rows will be passed to Reviews the average computation 14

Which Plan Will be Faster? Vs. Avg_agg • Query optimizer must pick between the two [Cnt, Sum] plans by estimating the cost of each Avg_agg [Cnt, Sum] • To estimate the cost of a plan, the QO must: Index Lookup o Estimate the selectivity of the predicate Filter MID = 932 MID=932 MID = 932 o Calculate the cost of both plans in terms MID of CPU time and I/O time Index Scan • The QO uses statistics about each table to make these estimates Reviews Reviews • The “best” plan depends on how many reviews there are for movie with MID = 932 Query Plan #1 Query Plan #2 ? ?or Best ? How many reviews for the movie Query Plan with MID = 932 will there be? 15

A Slightly More Complex Query • Consider the query: SELECT * FROM Reviews WHERE 7/1< date < 7/31 AND • Optimizer might first enumerate rating > 9 three physical plans: Cost = 100 Cost = 11 Cost = 25 seconds seconds seconds Filter Filter Filter Rating > 9 SF = .01 Rating > 9 7/1 < Date < 7/31 SF = .10 Filter Index Lookup Index Lookup 7/1 < Date > 7/31 SF = .10 7/1 < Date > 7/31 SF = .01 Rating > 9 Sequential Date Scan Index Rating Index Reviews Reviews Reviews • Then, estimate selectivity factors • Then, calculate total cost • Finally, pick the plan with the lowest cost 16

Query Optimization: The Main Steps Enumerate logically equivalent plans by applying ✓ 1 equivalence rules For each logically equivalent plan, enumerate all 2 alternative physical query plans Estimate the cost of each of the alternative 3 physical query plans 4 Run the plan with lowest estimated overall cost

Equivalence Rules Select and join operators commute with each other Select Select Select Select Join Join Reviews Customers Customers Reviews Customers Customers Join operators are associative Join Join Join Movies Customers Join Customers Reviews Reviews Movies 18

Equivalence Rules (cont.) Select operator distributes over joins Select Join Select Reviews Join Customers Reviews Customers Project Project operators [Name] cascade Project [Name] Project [CID, Name] Customers Customers 19

Example of Equivalent Logical Plans SELECT M.Title, M.Director FROM Movies M, Reviews R, Customers C Find titles and director names of WHERE C.City = “N.Y.” AND R.Rating > 7 movies with a rating > 7 from AND M.MID = R.MID AND C.CID = R.CID customers residing in NYC • One possible logical plan: Project M.Title, M.Director Join R.MID = M.MID Movies C.CID = R.CID Join Movies MID Title Director Earnings 1 C.City = “N.Y” Select Select R.Rating > 7 2 … Customers Customers Reviews Reviews CID Name Address City Date CID MID Rating 5 7/3 11 2 8 11 7/3 5 2 4 … … 20

Five Logically “Equivalent” Plans Project The “original” plan Project Selects distribute Join Join over joins rule Select Movies Join Movies Join Select Select Select Customers Reviews Project Customers Reviews Project Join Project Join Select Movies Join Select Movies Join Select Select Movies Select Select Join Customers Reviews Join Customers Reviews Customers Reviews Selects commute rule 21

Four More! Join Project The “original” plan Join Movies Project Select Select Select Customers Reviews Join Join commutativity rule Join Select Movies Customers Project Reviews Join Join Select Select Project Project commutativity rule Select Movies Customers Select Join Join Reviews Select Select Select Join Customers Join Customers Reviews Movies Reviews Movies 22

9 Logically Equivalent Plans, In Total Project Project Project Join Join Project Join Join Join Movies Select Movies Select Movies Select Join Movies Select Select Join Select Select Join Customers Reviews Select  All 9 logical Customers will produce the same result plans Reviews Customers Reviews Customers Reviews  For each of these 9 plans there is a large Project Project number of alternative physical plans that the optimizer can choose from Join Join Join Select Select Movies Select Project Movies Customers Project Select Join Select Project Select Reviews Join Join Join Customers Reviews Join Select Select Select Select Movies Customers Join Customers Join Customers Reviews Reviews Movies Reviews Movies 23

Query Optimization: The Main Steps Enumerate logically equivalent plans by applying ✓ 1 equivalence rules For each logically equivalent plan, enumerate all ✓ 2 alternative physical query plans Estimate the cost of each of the alternative 3 physical query plans 4 Run the plan with lowest estimated overall cost

Physical Plan Example • Assume that the optimizer has: o Three join strategies that it can select from: • nested loops (NL), sort-merge join (SMJ), and hash join (HJ) o Two selection strategies: • sequential scan (SS) and index scan (IS) • Consider one of the 9 logical plans • There are actually 36 possible physical alternatives for this single logical plan. Project (I was too lazy to draw pictures of all 36). Join • With 9 equivalent logical plans, there are 324 = (9 * 36) physical plans that the Join Movies optimizer must enumerate and cost as part of the search for the best Select Select execution plan for the query Customers Reviews And this was a VERY simple query! • • Here we onelook at how dynamic programming isProject to explore the space Later is will possible physical plan used NL of logical and physical plans w/o enumerating the entire plan space HJ Movies SS IS Customers Reviews 25

Query Optimization: The Main Steps Enumerate logically equivalent plans by applying ✓ 1 equivalence rules For each logically equivalent plan, enumerate all ✓ 2 alternative physical query plans ✓3 Estimate the cost of each of the alternative physical query plans. • Estimate the selectivity factor and output cardinality of each predicate • Estimate the cost of each operator 4 Run the plan with lowest estimated overall cost

Selectivity Estimation • Task of estimating how many rows will satisfy a predicate such as Movies.MID=932 • Plan quality is highly dependent on quality of the estimates that the query optimizer makes • Histograms are the standard technique used to estimate 5 selectivity factors for 4 predicates on a single table 3 2 • Many different flavors: 1 o Equi-Width 0 o Equi-Height o Max-Diff o … 27

Histogram Motivation # of Reviews for each customer Some examples: (total of 939 rows) 180 157 #1) Predicate: CID = 9 160 Actual Sel. Factor = 55/939 = .059 140 125 120 #2) Predicate: 2 <= CID <= 3 100 83 83 Actual Sel. Factor = 135/939 = .144 80 52 55 56 56 60 48 43 37 38 37 40 In general, there is not enough 17 19 20 5 6 10 5 7 space in the catalogs to store 0 summary statistics for each 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Customer ID (CID) values in Reviews Table distinct attribute value The solution: histograms 28

Equi-Width Histogram Example All buckets cover roughly the Count same key range 180 160 140 120 100 Example #1: Predicate: CID = 9 80 Example #2: Predicate: CID = 5 60 Actual Sel. Factor = 55/939= .059 40 Actual Sel. Factor = 10/939 = .011 Estimated Sel. Factor = (186/4)/939 = .050 20 Estimated Sel. Factor = (309/4)/993 =.082 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 CID Values Count 350 309 Yikes! 8X error!! 300 250 206 200 186 146 150 92 100 50 0 1-4 5-8 9-12 13-16 17-20 Equi-width histogram 29

Equi-Height Histograms Count 180 160 140 120 100 Divide ranges so that all 80 buckets contain roughly the 60 same number of values 40 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Count 200 175 156 157 161 142 148 150 100 50 0 1-5 6 7-8 9-11 12-15 16-20 Equi-height histogram 30

Equi-width vs. Equi-Height Equi-width 350 309 300 250 206 200 186 Example #2: Predicate: CID = 6 150 146 Example #1: Predicate: CID = 5 Actual Sel. Factor = 157/939 = .167 100 92 Actual Sel. Factor = 10/939 = .011 Estimated Sel. Factor = (309/4)/993 = .082 50 Estimated Sel. Factor = (309/4)/993 =.082 0 1-4 5-8 9-12 13-16 17-20 Equi-height 200 175 156 157 161 142 148 150 Example #1: Predicate: CID = 56 Example #2: Predicate: CID = 100 Actual Sel. Factor = 10/939 = = .167 Actual Sel. Factor = 157/939 .011 50 Estimated Sel. Factor = (156/5)/993 = .033 Estimated Sel. Factor = (157/1)/993 = .167 0 1-5 6 7-8 9-11 12-15 16-20 31

Histogram Summary • Histograms are a critical tool for estimating selectivity factors for selection predicates Errors still occur, however! • Other statistics stored by the DBMS for each table include # of rows, # of pages, … 32

Query Optimization: The Main Steps Enumerate logically equivalent plans by applying ✓ 1 equivalence rules For each logically equivalent plan, enumerate all ✓ 2 alternative physical query plans ✓3 Estimate the cost of each of the alternative physical query plans. • Estimate the selectivity factor and output cardinality of each predicate • Estimate the cost of each operator 4 Run the plan with lowest estimated overall cost

Estimating Costs • Two key costs that the optimizer considers: o I/O time – cost of reading pages from mass storage o CPU time – cost of applying predicates and operating on tuples in memory • Actual values are highly dependent on CPU and I/O subsystem on which the vs. query will be run o Further complicating the job of the query optimizer • For a parallel database system such as PDW, the cost of redistributing/shuffling rows must also be considered o Were you paying attention or updating your Facebook page when I talked about parallel query processing 2 years ago? 34

An Example Reviews Date CID MID Rating • Query: o SELECT Avg(Rating) FROM Reviews WHERE MID = 932 • Two physical query plans: Avg_agg Avg_agg [Cnt, Sum] [Cnt, Sum] Index Lookup Filter MID = 932 Which plan is MID = 932 cheaper ??? Sequential MID Scan Index Reviews Reviews Plan #1 Plan #2 35

Plan #1 Optimizer estimates total execution time of 9 seconds Avg_agg • Average computation • At 0.1 microseconds/row, avg [Cnt, Sum] is applied to 100 rows consumes .00001 seconds of CPU time • Filter is applied to 10M Filter rows • At 0.1 microseconds/row, filter MID = 932 • The optimizer consumes 1 second of CPU time estimates that 100 rows will satisfy the predicate Scan • Table is 100K pages • Reviews is scanned sequentially at with 100 rows/page 100 MB/second • Sorted on date • I/O time of scan is 8 seconds Reviews 36

Plan #2 Optimizer estimates total execution time of 0.3 seconds • At 0.1 Avg_agg • Average computation is microseconds/row, averag [Cnt, Sum] applied to 100 rows e consumes .00001 seconds of CPU time Index Lookup • 100 rows are estimated • 100 rows are retrieved using the MID = 932 to satisfy the predicate MID index • Since table is sorted on date field (and not MID field), each I/O MID requires a random disk I/O – Index about .003 seconds per disk I/O • I/O time will be .3 seconds Reviews The estimate for Plan #1 was 9 seconds, so Plan #2 is clearly the better 37 choice

But … • What if the estimate of the number of rows that satisfy the predicate MID = 932 is WRONG? o E.g. 10,000 rows instead of 100 rows Sequential scan is 100 better here Time (#sec) 10 Non-clustered 1 Index is better here 0.1 0.01 10 100 1,000 10,000 100,000 # of rows Sequential Scan Non-Clustered Index 38

Estimating Join Costs • Three basic join methods: M.Title, M.Director Project o Nested-loops join R.MID = M.MID o Sort-merge join Join o Hash-join C.CID = R.CID Join Movies • Very different performance C.City = “NY” Select Select R.Rating > 7 characteristics Customers Reviews • Critical for optimizer to carefully pick which method to use when 39

Sort-Merge Join Algorithm Sort Reviews on MID column (unless already sorted) Cost = 4 * |R| I/Os Reviews.MID = Merge Movies.MID Join Sort Movies on MID column (unless already sorted) Cost = 4 * |M| I/Os “Merge” two sorted tables: Sort Sort Scan each table sequential in tandem { For current row r of Reviews For current row m of Movies Cost = |R| + |M| I/Os if r.MID = m.MID produce output row Advance r and m cursors } Reviews Movies (|R| pages) (|M| pages) Total I/O cost = 5*|R| + 5*|M| I/Os Main Idea: Sort R and M on the join column (MID), then scan them to do a ``merge’’ (on join column), and output result tuples. 40

Nested-Loops Join For each page Ri, 1≤ i ≤ |R|, of Reviews { Read page Ri from disk For each Mj, 1≤ j ≤ |M|, of Movies { Read page Mj from disk For all rows r on page Ri Reviews.MID = Nested Loops Movies.MID { Join For all rows m on page Mj { if r.MID = m.MID produce output row } } } } Reviews Movies (|R| pages) (|M| pages) I/O Cost = |R| + |R| * |M| Main Idea: Scan R, and for each tuple in R probe tuples in M (by scanning it). Output result tuples. 41

Index-Nested Loops For each page Ri, 1≤ i ≤ |R|, of Reviews { Read page Ri from disk Reviews.MID = Nested Loops For all rows r on page Ri Movies.MID Join { Use MID index on Movies to fetch rows with MID attributes = r.MID Index Lookup Form output row for each returned row using r.MID } } Reviews Cost = |R| + |R| * (||R||/|R|) * 2 (|R| pages)that since Reviews is ordered on Notice • 2 I/Os: 1 index I/O + 1 movie I/O as Sorted on date column(and not MID), so each the Date column MID Reviews table is sorted on date column row of the Movies table retrieved incurs Index two random disk I/Os: Movies • ||R|| is # of rows in R • one to the index and (|M| pages) • one to the table • ||R||/|R| gives the average number of rows of R per page Main Idea: Scan R, and for each tuple in R probe tuples in M (by probing its index). Output result tuples. 42

Estimating Result Cardinalities • Consider the query SELECT * FROM Reviews WHERE 7/1 < date < 7/31 AND rating > 9 • Assume Reviews has 1M rows • Assume following selectivity factors: Sel. Factor # of qualifying rows 7/1 < date < 7/31 0.1 100,000 Review > 9 0.01 10,000 • How many output rows will the query produce? o If predicates are not correlated • .1 * .01 * 1M = 1,000 rows o If predicates are correlated could be as high as • .1 * 1M = 100,000 rows Why does this matter? 43

This is Why! Project Assume that: Join R.MID = M.MID • Reviews table is 10,000 pages Rating > 9 and with 80 rows/page 7/1 < date < 7/31 Select Movies • Movies table is 2,000 pages Reviews • The primary index on Movies is on the MID column 10000 Note that each join algorithm 1000 has a region where it provides the best performance Time (#sec) 100 N INL L SM 10 The consequences of incorrectly estimating the 1 selectivity of the predicate 0.000001 0.00001 0.0001 0.001 0.01 0.1 1 on Reviews can be HUGE Selectivity factor of predicate on Reviews table Nested Loops Sort Merge Index NL 44

Multidimensional Histograms • Used to capture correlation between attributes • A 2-D example 500 466 450 392 363 361 400 314 289 343 258 350 211 269 315 249 238 175 319 144 212 216 300 191 97 192 303 250 229 98 196 102 198 200 151 150 152 156 100 50 0 45

A Little Bit About Estimating Join Cardinalities • Question: Given a join of R and S, what is the range of possible result sizes (in #of tuples)? o Suppose the join is on a key for R and S Students(sid, sname, did), Dorm(did,d.addr) Select S.sid, D.address From Students S, Dorms D Where S.did = D.did What is the cardinality? A student can only live in at most 1 dorm: • each S tuple can match with at most 1 D tuple • cardinality (S join D) = cardinality of S 46

Estimating Join Cardinality • General case: join on {A} (where {A} is key for neither) o estimate each tuple r of R generates uniform number of matches in S and each tuple s of S generates uniform number of matches in R, e.g. SF = min(||R|| * ||S|| / NKeys(A,S) = 100*20/10 = 200 ||S|| * ||R|| / NKeys(A,R)) = 20*100/75 = 26.6 e.g., SELECT M.title, R.title FROM Movies M, Reviews R WHERE M.title = R.title Movies: 100 tuples, 75 unique titles  1.3 rows for each title Reviews: 20 tuples, 10 unique titles  2 rows for each title

Query Optimization: The Main Steps Enumerate logically equivalent plans by applying Enumerate ✓ 1 equivalence rules For each logically equivalent plan, enumerate all enumerate ✓ 2 alternative physical query plans ✓3 How big costthe plan space Estimate the is of each of the alternative physical query plans. for a query involving N tables? • Estimate the selectivity factor and output cardinality of each predicate • Estimate the cost of each operator It turns out that the answer depends 4 Run the plan“shape” of the query overall cost on the with lowest estimated

Two Common Query “Shapes” “Star” Join Queries B Number of logically equivalent alternatives Join # of Tables Star Chain A Join F Join C 2 2 2 4 48 40 Join 5 384 224 D 6 3,840 1,344 8 645,120 54,912 10 18,579,450 2,489,344 “Chain” Join Queries A Join B Join C Join D Join F In practice, “typical” queries fall somewhere between these two extremes 49

Pruning the Plan Space • Consider only left-deep query plans to reduce the search space Left Deep Join Bushy Join Solution: Join These are counts of logical E plans only! Join Join Join D Join With: A B Use some form of dynamic programming C Join C D (either bottom A orBtop down)3 join methods E up i) ii) n joins in a query to search the plan space heuristicallybe 3n physical There will Star Join Queries Chain Join Queries plans for each logical plan Example: # of Tables Bushy Sometimes these heuristics will Left-Deep Bushy Left Deep 2 a left-deep, 82table star join query there will be: For 2 2 2 4 cause the best plan to be missed!! 48 12 40 8 5i) 10,080 different logical plans 384 48 224 16 ii) 22,044,960 different physical plans!! 6 3,840 240 1,344 32 8 645,120 10,080 54,912 128 10 18,579,450 725,760 2,489,344 512 50

Bottom-Up QO Using Dynamic Programming • Optimization is performed in N passes (if N relations are joined): o Pass 1: Find the best (lowest cost) 1-relation plan for each relation. o Pass 2: Find the best way to join the result of each orders include the Interesting 1-relation plan (as orders that facilitate the outer/left table) to another relation (as the inner/right table) to generate all 2-relation plans. execution of o Pass N: Find best way to join resultjoins, aggregates, and order byto the of a (N-1)-relation plan (as outer) N’th relation to generate all N-relation clauses subsequently by the plans. • At each pass, for each subset of relations, prune query all plans except those o Lowest cost plan overall, plus o Lowest cost plan for each interesting order of the rows • Order by, group by, aggregates etc. handled as the final step In spite of pruning plan space, this approach is still exponential in the # of tables.

An Example: Select Join B Join Select Legend: SS – sequential scan A Join C IS – index scan 5 – cost Select D First, generate all single relation plans: A B C D All tables 13 SS IS 27 SS 73 38 SS IS 18 42 SS IS 95 All single relation plans A A B C C D D Prune 52

Then, All Two Relation Plans 13 SS 27 SS 73 18 42 SS All single IS IS relation plans A B D A C after pruning 53

Two Relation Plans Select Join B Join Select A Join C Starting With A Select D 13 SS 27 SS 73 18 42 SS Single IS IS relation A A B C D plans A.a = B.a Join NLJ SMJ NLJ SMJ Select B SS SS SS SS SS SS IS IS A A B B A B A B A 1013 315 822 293 Prune Let’s assume there are 2 alternative join methods for the QO to select from: 1. NLJ = Nested Loops Join 2. SMJ = Sort Merge Join 54

Two Relation Plans Select A Join B Join Join Select C Starting With B Select D 13 SS 27 SS 73 18 42 SS Single IS IS relation A A B C D plans NLJ SMJ NLJ SMJ SS SS SS SS SS SS IS IS B A B A B B A A 1013 315 756 293 B.b = D.b Join NLJ SMJ NLJ SMJ B Select SS SS SS SS SS SS D IS IS B D B D B B C C 1520 432 2321 932 Prune 55

Two Relation Plans Select A Join B Join Join Select C Starting With C Select D 13 SS 27 SS 73 18 42 SS Single IS IS relation A B D plans A C B.C = C.c Join NLJ SMJ Select B SS SS IS IS C B B C C 6520 932 Prune 56

Two Relation Plans Select A Join B Join Join Select C Starting With D Select D 13 SS 27 SS 73 18 42 SS Single IS IS relation A B D A C plans NLJ SMJ B.b = D.b Join SS SS SS SS Select B D B D B D 1520 432 Prune 57

Next, All Three Select Join B Join Select A Join C Relation Plans Select D SMJ SMJ SMJ SMJ SMJ SMJ Pruned SS SS SS SS SS SS SS SS IS IS IS IS two relation B B B D D B B B plans A A C C 58

Next, All Three Select A Join B Join Join Select C Relation Plans Select D SMJ SMJ SMJ SS SS SS SS Fully pruned two IS IS relation plans A B B D C B NLJ NLJ SMJ SMJ SS IS SS SS D 1) Considering the Two IS C IS Relation Plans That B B A A Started With A SMJ SMJ SMJ SMJ SS IS SS SS D IS C IS B A B A 59

Next, All Three Select A Join B Join Join Select C Relation Plans Select D SMJ SMJ SMJ Fully pruned IS SS SS SS IS SS two relation plans A B B D C B NLJ NLJ NLJ SMJ SS SMJ IS SMJ IS SS SS A SS SS A SS SS C 2) Considering B D B D B D the Two Relation Plans SMJ SMJ SMJ That Started SS With B SMJ IS IS SMJ SMJ SS SS A SS SS A SS SS C B D B D B D 60

Next, All Three Select A Join B Join Join Select C Relation Plans Select D SMJ SMJ SMJ SS SS IS SS IS SS Fully pruned two B B D B relation plans A C NLJ NLJ SMJ SMJ SS IS SS SS D IS A IS 3) Considering the B C B C Two Relation Plans SMJ SMJ That Started With C SMJ SMJ SS IS SS SS D IS A IS B C B C 61

You Have Now Seen the Theory • But the reality is: o Optimizer still pick bad plans too frequently for a variety of reasons: • Statistics can be missing, out-of-date, incorrect • Cardinality estimates assume uniformly distributed values but data values are skewed • Attribute values are correlated with one another: o Make = “Honda” and Model = “Accord” • Cost estimates are based on formulas that do not take into account the characteristics of the machine on which the query will actually be run o Regressions happen due hardware and software upgrades What can be done to improve the situation? 62

Opportunities for Improvement • Develop tools that give us a better understanding of what goes wrong • Improve plan stability • Use of feedback from the QE to QO to improve statistics and cost estimates • Dynamic re-optimization 63

Towards a Better Understanding of QO Behavior • Picasso Project – Jayant Haritsa, IIT Bangalore o Bing “Picasso Haritsa” to find the project’s web site o Tool is available for SQL Server, Oracle, PostgreSQL, DB2, Sybase • Simple but powerful idea: • For a given query such as SELECT * from A, B WHERE A.a = B.b and A.c <= constant-1 and B.d <= constant-2 • Systematically vary constant-1 and constant-2 • Obtain query plan and estimated cost from the query optimizer for each combination of input parameters • Plot the results 64

Example: TPC-H Query 8 select o_year, sum(case when nation = 'BRAZIL' then volume else 0 end) / sum(volume) from ( select YEAR(O_ORDERDATE) as o_year, L_EXTENDEDPRICE * (1 - L_DISCOUNT) as volume, n2.N_NAME as nation from PART, SUPPLIER, LINEITEM, ORDERS, CUSTOMER, NATION n1, NATION n2, REGION where P_PARTKEY = L_PARTKEY and S_SUPPKEY = L_SUPPKEY and L_ORDERKEY = O_ORDERKEY and O_CUSTKEY = C_CUSTKEY and C_NATIONKEY = n1.N_NATIONKEY and n1.N_REGIONKEY = R_REGIONKEY and R_NAME = 'AMERICA„ and S_NATIONKEY = n2.N_NATIONKEY and O_ORDERDATE between '1995-01-01' and '1996-12-31' and P_TYPE = 'ECONOMY ANODIZED STEEL' and S_ACCTBAL <= constant-1 and L_EXTENDEDPRICE <= constant-2 ) as all_nations group by o_year order by o_year

Resulting Plan Space • SQL Server 2008 R2 • A total of 90,000 queries o 300 different values for both L_ExtendedPrice and S_AcctBal • 204 different plans!! o Each distinct plan is assigned a unique color • Zooming in to the [0,20:0,20] region: Key takeaway: If plan choice is so sensitive to the constants used, it will undoubtedly be sensitive to errors in statistics and cardinality estimates  Intuitively, this seems very bad! 66

Estimated Execution Costs • Plan exhibits what is probably a “flaw” in the cost model: o As L_Extended price is increased, estimated cost first increases sharply before decreasing • Still a mystery why QO is indeed harder than rocket science!! 67

How Might We Do Better? • Recall this graph of join algorithm performance 10000 Time (#sec) Project 1000 N Rating > 9 and Join R.MID = M.MID 100 INL L SM 7/1 < date < 7/31 10 Select 1 Movies Reviews Selectivity factor of predicate on Reviews table Nested Loops Sort Merge Index NL • While the two “nested loops” algorithms are faster at low selectivity factors, they are not as “stable” across the entire range of selectivity factors 68

“Reduced” Plan Diagrams • Robustness is somehow tied to the number of plans o Fewer plans => more robust plans • For TPC-H query 8, it is possible to use only 30 plans (instead of 204) by picking more robust plans that are slightly slower (10% max, 2% avg) • Since each plan covers a larger region it will be less sensitive to errors in estimating cardinalities and costs Reduced plan space for TPC-H query 8 69

How Might We Do Better? • At QO time, have the QO annotate compiled query plans with statistics (e.g. expected cardinalities) and check operators INL INL Check IS SMJ IS SMJ A SS IS A Check Check C B SS IS C B • At runtime, check operators collect the actual statistics and compare actual vs. predicted • Opens up a number of avenues for improving QO performance o Build an optimizer that learns o Do dynamic reoptimization of “in flight” queries 70

Helping the Optimizer Learn INL Check Query Optimizer Query Plan IS Executor Database SMJ A Check Check Catalogs Statistics IS SS Original Observed Stats C B & Observed Statistics Tracker Optimization of subsequent queries benefits from the observed statistics 71

Dynamic Reoptimization 1) Observed output size of SMJ is 5x larger than expected INL Check Database Query Optimizer IS Query Plan Executor SMJ A Tmp1 Check Check SS IS 2) Output of SMJ is C B materialized as Tmp1 in tempdb INL Tmp1 IS Actual A Stats 3) Remainder of query is returned to the optimizer for reoptimization 72

Key Points To Remember For The Quiz • Query optimization is harder than rocket science o The other components are trivial in comparison • Three key phases of QO o Enumeration of logical plan space o Enumeration of alternative physical plans o Selectivity estimation and costing • The QO team of every DB vendor lives in fear of regressions o How exactly do you expect them to make forward progress?

And…If You’ve Spent My Entire Keynote Chatting on Facebook… At least, check out my lab “Microsoft Jim Gray Systems Lab”:

Many Thanks To: Rimma Nehme, Pooja Darera, Il-Sung Lee, Jeff Naughton, Jignesh Patel, Jennifer Widom and Donghui Zhang for their many useful suggestions and their help in debugging these slides 75

Finally… Thanks for inviting me to give a talk again 76

http://claysql.blogspot.com	216
http://static.slidesharecdn.com	4
http://twitter.com	2
http://www.claysql.blogspot.com	1
http://translate.googleusercontent.com	1
http://webcache.googleusercontent.com	1

PASS Summit 2010 Keynote David DeWitt

by GraySystemsLab on Nov 11, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 225

Statistics

PASS Summit 2010 Keynote David DeWitt — Presentation Transcript