1. Relational Query Optimization1

2. Review Choice of single-table operations
Depends on indexes, memory, stats,…
Joins
Block nested loops:
simple, exploits extra memory
Indexed nested loops:
good if 1 rel small and one indexed
Sort/Merge Join
good with small amount of memory, equal-size tables
Hash Join
good if one table much smaller, bad with skewed data
These are “rules of thumb”
On their way to a more principled approach…

3. Indexed Nested Loop Join Iterator
Big Picture Overview
SELECT S.name
FROM Reserves R, Sailors S
WHERE R.sid = S.sid
AND R.bid = 100
AND S.rating > 5
SQL Query
Query Parser
𝜋S.name(𝜎bid=100⋀rating>5(
Reserves ⋈R.sid=S.sid Sailors))
Relational Algebra
𝜋S.name
𝜎R.bid=100 ⋀ S.rating > 5
⋈R.sid=S.sid
Reserves
Sailors
(Logical) Query Plan:
Query Optimizer
⋈R.sid=S.sid
𝜋S.name
𝜎R.bid=100
Reserves
Sailors
𝜎S.rating>5
Optimized (Physical) Query Plan:
On-the-fly
Project Iterator
On-the-fly
Select Iterator
Indexed Nested Loop Join Iterator
B+-Tree
Indexed Scan Iterator
Operator Code
Heap Scan Iterator

4. Indexed Nested Loop Join Iterator
Big Picture Overview
SQL Query
𝜋S.name(𝜎bid=100⋀rating>5(
Reserves ⋈R.sid=S.sid Sailors))
Relational Algebra
SELECT S.name
FROM Reserves R, Sailors S
WHERE R.sid = S.sid
AND R.bid = 100
AND S.rating > 5
Query Parser
𝜋S.name
𝜎R.bid=100 ⋀ S.rating > 5
⋈R.sid=S.sid
Reserves
Sailors
(Logical) Query Plan:
Query Optimizer
⋈R.sid=S.sid
𝜋S.name
𝜎R.bid=100
Reserves
Sailors
𝜎S.rating>5
Optimized (Physical) Query Plan:
On-the-fly
Project Iterator
On-the-fly
Select Iterator
Indexed Nested Loop Join Iterator
B+-Tree
Indexed Scan Iterator
Operator Code
Heap Scan Iterator

5. Relational Operators as a Graph
𝜋sname(𝜋sid(𝜋bid(𝜎color=‘red’(Boats)) ⋈ Res) ⋈ Sailors)
𝜎color=‘red
Boats
𝜋bid
Reserves
Sailors
𝜋sname
𝜋sid ⋈
Query plan
Edges encode “flow” of tuples
Vertices = Operators
Source vertices = table access operators …
Also called dataflow graph

6. Query Executor Instantiates Operators
On-the-fly
Project Iterator
𝜋sname(𝜋sid(𝜋bid(𝜎color=‘red’(Boats)) ⋈ Res) ⋈ Sailors)
𝜎color=‘red
Boats
𝜋bid
Reserves
Sailors
𝜋sname
𝜋sid ⋈
Query planner selects operators
Each operator instance:
Implements iterator interface
Efficiently executes operator logic forwarding tuples to next operator
On-the-fly
Project Iterator
Indexed Nested Loop Join Iterator
On-the-fly
Project Iterator
On-the-fly
Select Iterator
B+-Tree
Indexed Scan Iterator
B+-Tree
Indexed Scan Iterator
B+-Tree
Indexed Scan Iterator
Operator Code

7. Query Optimization Overview
Query can be converted to relational algebra
Rel. Algebra converts to tree
Each operator has implementation choices
Operators can also be applied in different orders!
SELECT S.sname
FROM Reserves R, Sailors S
WHERE R.sid=S.sid AND
R.bid=100 AND S.rating>5
Reserves
Sailors
sid=sid
bid=100
rating > 5
sname
(sname)(bid=100  rating > 5) (Reserves ⨝ Sailors) 4

8. Query Optimization Overview (cont.)
Plan: Tree of R.A. ops (and some others) with choice of algorithm for each op.
Recall: Iterator interface (next()!)
Three main issues:
For a given query, what plans are considered?
How is the cost of a plan estimated?
How do we “search” in the “plan space”?
Ideally: Want to find best plan.
Reality: Avoid worst plans! 2

9. Cost-based Query Sub-System
Select *
From Blah B
Where B.blah = blah
Queries
Usually there is a
rewriting step before
the cost-based steps to
simplify queries (esp. to
“flatten” views and
subqueries).
Query Parser
Query Optimizer
Plan Generator
Plan Cost Estimator
Catalog Manager
Schema
Statistics
Query Executor

10. Schema for Examples
Sailors (sid: integer, sname: string, rating: integer, age: real)
Reserves (sid: integer, bid: integer, day: dates, rname: string)
As seen in previous lectures…
Reserves:
Each tuple is 40 bytes long, 100 tuples per page, 1000 pages.
Assume there are 100 boats
Sailors:
Each tuple is 50 bytes long, 80 tuples per page, 500 pages.
Assume there are 10 different ratings
Assume we have 5 pages in our buffer pool! 3

11. Motivating Example SELECT S.sname FROM Reserves R, Sailors S
WHERE R.sid=S.sid AND
R.bid=100 AND S.rating>5
Cost: *1000 I/Os
By no means the worst plan!
Misses several opportunities:
selections could be ‘pushed’ down
no use made of indexes
Goal of optimization: Find faster plans that compute the same answer.
Sailors
Reserves
sid=sid
bid=100
rating > 5
sname
(Page-Oriented
Nested loops)
(On-the-fly) 4

12. Sorting: 2-Way (a strawman)
Pass 0 (conquer):
read a page, sort it, write it.
only one buffer page is used
a repeated “batch job”
Sort in place
I/O
Buffer
INPUT
OUTPUT
RAM 5

13. Sorting: 2-Way (a strawman)
Pass 0 (conquer):
read a page, sort it, write it.
only one buffer page is used
a repeated “batch job”
Pass 1, 2, 3, …, etc. (merge):
requires 3 buffer pages
note: this has nothing to do with double buffering!
merge pairs of runs into runs twice as long
a streaming algorithm, as in the previous slide!
Input Buffer
Output
Buffer 1
INPUT
OUTPUT 3 2
Input Buffer 5

14. Two-Way External Merge Sort
Conquer and Merge: sort subfiles and merge
Each pass we read + write each page in file (2N)
N pages in the file. So, the number of passes is:
So total cost is:
3,4
6,2
9,4
8,7
5,6
3,1 2
Input file
PASS 0
3,4
2,6
4,9
7,8
5,6
1,3 2
1-page runs
PASS 1
2,3
4,7
1,3
2-page runs
4,6
8,9
5,6 2
PASS 2
2,3
4,4
1,2
4-page runs
6,7
3,5
8,9 6
PASS 3
1,2
2,3
3,4
8-page runs
4,5
6,6
7,8 9 6

15. General External Merge Sort
More than 3 buffer pages. How can we utilize them?
To sort a file with N pages using B buffer pages:
Pass 0: use B buffer pages. Produce sorted runs of B pages each.
Pass 1, 2, …, etc.: merge B-1 runs at a time.
Conquer
Merge B 1
...
B-1 1
...
⌈N/B⌉
Sorted Runs length B
Sorted Runs
Length B(B-1) 7

16. Cost of External Merge Sort
Number of passes:
Cost = 2N * (# of passes)
E.g., with 5 buffer pages, to sort 108 page file:
Pass 0: = 22 sorted runs of 5 pages each (last run is only 3 pages)
Pass 1: = 6 sorted runs of 20 pages each (last run is only 8 pages)
Pass 2: 2 sorted runs, 80 pages and 28 pages
Pass 3: Sorted file of 108 pages
Formula check: 1+┌log4 22┐= 1+3  4 passes √ 8

17. Memory Requirement for External Sorting
How big of a table can we sort in two passes?
Each “sorted run” after Phase 0 is of size B
Can merge up to B-1 sorted runs in Phase 1
Answer: B(B-1).
Sort N pages of data in about space 1
...
B-1 B
⌈N/B⌉
Conquer
Merge
Sorted Runs length B
Sorted Runs
Length B(B-1)

18. Block Nested Loop Join Cost: (Assume B = 102) ([R]/(B-2)) * [S] + [R]
Assume B Pages of Memory
foreach block bR of B-2 pages in R do
foreach page bS in S do
foreach record r in bR do
foreach record s in bSdo
if θ(ri,sj) then add <r, s> to result
R S: R
Cost: (Assume B = 102)
([R]/(B-2)) * [S] + [R]
10 * ,000
6,000
Swap R and S?
([S] /(B-2)) * [R] + [S]
5 * 1,
5,500
@10ms  55 seconds!
Can we do better?
B - 2 Memory
What if smaller relation (S) was “outer”? Looking at arithmetic we can get a small savings by doing the scan on the outside look at the additive term.
Wait what about when p_r is small. If there is one record per page of R we might want it to be the outer
What about buffer? If S fits in memory then io costs are [R] and [S]
Lets get rid of the p_r S
[R]=1000, pR=100, |R| = 100,000
[S]=500, pS=80, |S| = 40,000

19. Cost of Sort-Merge Join
Read
In Memory
Sort
B – 2 Buffers
Buffer
Write
Sorted
Runs
Read
Merge
Runs
Out Buffer
B – 1
Input
Buffers
Write
Sorted
Files
Read
Merge
Files
Out Buffer
B – 1
Input
Buffers ?
Sorting Phase
Merging Phase
Cost: Sort R + Sort S + ([R]+[S])
But in worst case, last term could be [R]*[S] (very unlikely!)
Q: what is worst case?
Suppose buffer B > Sqrt(max([R], [S])):
Both R and S can be sorted in 2 passes
Total join cost = 4* *500 + ( ) = 7500
Comparisons:
Indexed Nested Loop: 80,500
Block Nested Loop: 5,500
Grace Hash Join: 4,500
Assume memory is greater than Sqrt(R) and Sqrt(S) 1 read of input  1 write of runs  1 read for merge of runs so 3R + 3S
Worst case is due to nested loop
[R]=1000, pR=100, |R| = 100,000
[S]=500, pS=80, |S| = 40,000

20. Sort-Merge Join Considerations
Read
In Memory
Sort
B – 2 Buffers
Buffer
Write
Sorted
Runs
Read
Merge
Runs
Out Buffer
B – 1
Input
Buffers
Write
Sorted
Files
Read
Merge
Files
Out Buffer
B – 1
Input
Buffers
Merging Phase ?
Sorting Phase
An important refinement (needs 2x buffers):
Do the join during the final merging pass of sort
Read R and write out sorted runs (pass 0)
Read S and write out sorted runs (pass 0)
Merge R-runs and S-runs, while finding R ⋈ S matches
Cost = 3*[R] + 3*[S]
Sort-merge join an especially good choice if:
one or both inputs are already sorted on join attribute(s)
output is required to be sorted on join attributes(s)
Assume memory is greater than Sqrt(R) and Sqrt(S) 1 read of input  1 write of runs  1 read for merge of runs so 3R + 3S
Worst case is due to nested loop

21. More Alternative Plans (No Indexes)
Reserves
Sailors
sid=sid
bid=100
sname
(On-the-fly)
rating > 5
(Scan;
write to
temp T1)
temp T2)
(Sort-Merge Join)
More Alternative Plans (No Indexes)
Sort Merge Join
With 5 buffers, cost of plan:
Scan Reserves (1000) + write temp T1 (10 pages) = 1010.
Scan Sailors (500) + write temp T2 (250 pages) = 750.
Sort T1 (2*2*10) + sort T2 (2*4*250) + merge (10+250) = 2300
Total: page I/Os.
If use Block NL join, join = 10+4*250, total cost = 2770.
Can also `push’ projections, but must be careful!
T1 has only sid, T2 only sid, sname:
T1 fits in 3 pgs, cost of Chunk NL under 250 pgs, total < 2000. 5

22. Index Nested Loops Join
R S:
foreach tuple r in R do
foreach tuple s in S where ri == sj do
add <r, s> to result
Cost = [R] + ([R] * pR) * cost to find matching S tuples
If index uses Alt. 1  cost to traverse tree from root to leaf. (e.g., 2-4 IOs)
For Alt. 2 or 3:
Cost to lookup RID(s); typically 2-4 IOs for B+Tree.
Cost to retrieve records from RID(s); depends on clustering.
Clustered index: 1 I/O per page of matching S tuples.
Unclustered: up to 1 I/O per matching S tuple (w/o sorting)

23. Index Nested Loops Join
R S:
foreach tuple r in R do
foreach tuple s in S where ri == sj do
add <r, s> to result
Cost = [R] + ([R] * pR) * cost to find matching S tuples
Assume alternative 2 (by reference) unclustered
1 matching tuple (e.g., primary key lookup)
only leaves and data entries not in cache  2 IOs
Cost:
R⋈S: (1,000*100)*2 = 201,000
S⋈R: (500*80)*2 = 80,500  13 Minutes
Block Nested Loop: 5,500
55 Seconds …
[R]=1,000, pR=100, |R| = 100,000
[S]=500, pS=80, |S| = 40,000

24. More Alt Plans: Indexes
(On-the-fly)
sname
With clustered index on bid of Reserves, we access:
100,000/100 = 1000 tuples on 1000/100 = 10 pages.
INL with outer not materialized.
(On-the-fly)
rating > 5
(Index Nested Loops,
sid=sid
with pipelining )
(Use B+-tree
do not write
to temp)
bid=100
Sailors
Projecting out unnecessary fields from outer doesn’t make an I/O difference.
Reserves
Join column sid is a key for Sailors.
At most one matching tuple, unclustered index on sid OK.
Decision not to push rating>5 before the join is based on
availability of sid index on Sailors.
Cost: Selection of Reserves tuples (10 I/Os); then, for each,
must get matching Sailors tuple (1000*1.2); total 1210 I/Os. 6

25. Summing up There are lots of plans
Even for a relatively simple query
Engineers often think they can pick good ones
MapReduce API was based on that assumption
Not so clear that’s true!
Manual query planning can be tedious, technical
Witness the rise of Hive, SparkSQL, despite immature optimizers
Machines are better at enumerating options than people
But we will see soon how optimizers make simplifying assumptions

26. What is needed for optimization?
Given: A closed set of operators
Relational ops (table in, table out)
Encapsulation (e.g. based on iterators)
Plan space
Based on relational equivalences, different implementations
Cost Estimation based on
Cost formulas
Size estimation, in turn based on
Catalog information on base tables
Selectivity (Reduction Factor) estimation
A search algorithm
To sift through the plan space and find lowest cost option!

27. Query Optimization We’ll focus on “System R” (“Selinger”) optimizers
“Cascades” optimizer is the other common one
Later, with notable differences, but similar big picture

28. Highlights of System R Optimizer
Works well for joins.
Plan Space: Too large, must be pruned.
Many plans share common, “overpriced” subtrees
ignore them all!
In some implementations, only consider left-deep plans
In some implementations, Cartesian products avoided
Cost estimation
Very inexact, but works ok in practice.
Stats in system catalogs used to estimate sizes & costs
Considers combination of CPU and I/O costs.
System R’s scheme has been improved since that time.
Search Algorithm: Dynamic Programming 2

29. Query Optimization
Plan Space
Cost Estimation
Search Algorithm

30. Query Blocks: Units of Optimization
SELECT S.sname
FROM Sailors S
WHERE S.age IN
(SELECT MAX (S2.age)
FROM Sailors S2
GROUP BY S2.rating)
Break query into query blocks
Optimize one block at a time
Uncorrelated nested blocks computed once
Correlated nested blocks like function calls
But sometimes can be “decorrelated”
Beyond the scope of CS150!
Outer block
Nested block
For each block, the plans considered are:
All available access methods, for each relation in FROM clause.
All left-deep join trees
right branch always a base table
consider all join orders and join methods B A C D 7

31. Schema for Examples
Sailors (sid: integer, sname: string, rating: integer, age: real)
Reserves (sid: integer, bid: integer, day: dates, rname: string)
Reserves:
Each tuple is 40 bytes long, 100 tuples per page, 1000 pages distinct bids.
Sailors:
Each tuple is 50 bytes long, 80 tuples per page, 500 pages. 10 ratings, 40,000 sids. 3

32. Translating SQL to Relational Algebra
SELECT S.sid, MIN (R.day)
FROM Sailors S, Reserves R, Boats B
WHERE S.sid = R.sid AND R.bid = B.bid AND B.color = “red”
GROUP BY S.sid
HAVING COUNT (*) >= 2
For each sailor with at least two reservations for red boats, find the sailor id and the earliest date on which the sailor has a reservation for a red boat. 7

33. Translating SQL to “Relational Algebra”
SELECT S.sid, MIN (R.day)
FROM Sailors S, Reserves R, Boats B
WHERE S.sid = R.sid AND R.bid = B.bid AND B.color = “red”
GROUP BY S.sid
HAVING COUNT (*) >= 2 p
S.sid, MIN(R.day)
(HAVING COUNT(*)>2 (
GROUP BY S.Sid (
sB.color = “red” (
Sailors Reserves Boats)))) 7

34. Recall R. A. Equivalences
Allow us to choose different join orders and to “push” selections and projections ahead of joins.
Selections:
c1…cn(R)  c1(…(cn(R))…) (cascade)
c1(c2(R))  c2(c1(R)) (commute)
Projections:
a1(R)  a1(…(a1, …, an-1(R))…) (cascade)
Cartesian Product
R  (S  T)  (R  S)  T (associative)
R  S  S  R (commutative)
This means we can do joins in any order.
But…beware of cartesian product!
(R ⋈ S) ⋈ T  (R  T) ⋈ S 10

35. More R. A. Equivalences Eager projection
Can cascade and “push” (some) projections thru selection
Can cascade and “push” (some) projections below one side of a join
Rule of thumb: can project anything not needed “downstream”
a1( c1(R) )  a1( c1( a1,c1 (R) ) )
Selection on a cross-product is equivalent to a join.
If selection is comparing attributes from each side
E.g. R.a=S.b(R x S)  R ⨝R.a=S.b S
A selection only on attributes of R commutes with R ⨝ S.
i.e., (R ⨝ S)  (R) ⨝ S
but only if the selection doesn’t refer to S! 11

36. “Physical” Equivalences
Certain “physical” operators not in the Algebra can affect plan cost without affecting answers
E.g. Index scan (iteration through result is sorted)
E.g. Sort (iteration through result is sorted)
E.g. Hash (iteration through result is grouped)
Some are tradeoffs
E.g. Index scan vs. Heap scan
E.g. Sort-Merge join vs. Index NL join
Others are optional cost/benefit add-ons
E.g. Insert a Sort iterator into a plan

37. Queries Over Multiple Relations
A System R heuristic: only left-deep join trees considered.
Restricts the search space
Left-deep trees allow us to generate all fully pipelined plans.
Intermediate results not written to temporary files.
Not all left-deep trees are fully pipelined (e.g., SM join). B A C D C D B A 15

38. Query Optimization
Plan Space
Cost Estimation
Search Algorithm

39. Cost Estimation For each plan considered, must estimate total cost:
Must estimate cost of each operation in plan tree.
Depends on input cardinalities.
We’ve already discussed this for various operators
sequential scan, index scan, joins, etc.
Must estimate size of result for each operation in tree!
Because it determines downstream input cardinalities!
Use information about the input relations.
For selections and joins, assume independence of predicates.
In System R, cost is boiled down to a single number consisting of #I/O + CPU-factor * #tuples
Q: Is “cost” the same as estimated “run time”? 8

40. Statistics and Catalogs
Need info on relations and indexes involved.
Catalogs typically contain at least:
Catalogs updated periodically.
Too expensive to do continuously
Lots of approximation anyway, so a little slop here is ok.
Modern systems do more
Esp. keep more detailed statistical information on data values
e.g., histograms
Statistic
Meaning
NTuples
# of tuples in a table (cardinality)
NPages
# of disk pages in a table
Low/High
min/max value in a column
Nkeys
# of distinct values in a column
IHeight
the height of an index
INPages
# of disk pages in an index 8

41. Size Estimation and Selectivity
SELECT attribute list
FROM relation list
WHERE term1 AND ... AND termk
Max output cardinality = product of input cardinalities
Selectivity (sel) associated with each term
reflects the impact of the term in reducing result size.
|output| / |input|
Result cardinality = Max # tuples * ∏seli
Book calls selectivity “Reduction Factor” (RF)
Avoid confusion:
“highly selective” in common English is opposite of a high selectivity value (|output|/|input| high!) 9

42. Result Size Estimation
Result cardinality = Max # tuples * product of all RF’s.
Term col=value (given Nkeys(I) on col)
RF = 1/NKeys(I)
Term col1=col (handy for joins too…)
RF = 1/MAX(NKeys(I1), NKeys(I2))
Why MAX? See bunnies on next slide…
Term col>value
RF = (High(I)-value)/(High(I)-Low(I) + 1)
Implicit assumptions: values are uniformly distributed and terms are independent!
Note, if missing the needed stats, assume 1/10!!! 9