1. CSE 544: Optimizations
Wednesday, 5/10/2006

2. The three components of an optimizer
We need three things in an optimizer:
A space of plans (e.g. algebraic laws)
An optimization algorithm
A cost estimator

3. Algebraic Laws Commutative and Associative Laws Distributive Laws
R  S = S  R, R  (S  T) = (R  S)  T
R || S = S || R, R || (S || T) = (R || S) || T
Distributive Laws
R || (S  T) = (R || S)  (R || T)

4. Algebraic Laws Laws involving selection:
s C AND C’(R) = s C(s C’(R)) = s C(R) ∩ s C’(R)
s C OR C’(R) = s C(R) U s C’(R)
s C (R || S) = s C (R) || S
When C involves only attributes of R
s C (R – S) = s C (R) – S
s C (R  S) = s C (R)  s C (S)
s C (R || S) = s C (R) || S

5. Algebraic Laws Example: R(A, B, C, D), S(E, F, G)
s F=3 (R || D=E S) = ?
s A=5 AND G=9 (R || D=E S) = ?

6. Algebraic Laws Laws involving projections
PM(R || S) = PM(PP(R) || PQ(S))
PM(PN(R)) = PM,N(R)
Example R(A,B,C,D), S(E, F, G)
PA,B,G(R || D=E S) = P ? (P?(R) || D=E P?(S))

7. Algebraic Laws Laws involving grouping and aggregation:
(A, agg(B)(R)) = A, agg(B)(R)
A, agg(B)((R)) = A, agg(B)(R) if agg is “duplicate insensitive”
Which of the following are “duplicate insensitive” ? sum, count, avg, min, max
A, agg(D)(R(A,B) || B=C S(C,D)) = A, agg(D)(R(A,B) || B=C (C, agg(D)S(C,D)))

8. Join Trees R1 || R2 || …. || Rn Join tree: A plan = a join tree
A partial plan = a subtree of a join tree R3 R1 R2 R4

9. Types of Join Trees
Left deep: R4 R2 R5 R3 R1

10. Types of Join Trees
Bushy: R3 R2 R4 R1 R5

11. Types of Join Trees
Right deep: R3 R1 R5 R2 R4

12. Optimization Algorithms
Heuristic based
Cost based
Dynamic programming: System R
Rule-based optimizations: DB2, SQL-Server

13. Heuristic Based Optimizations
Query rewriting based on algebraic laws
Result in better queries most of the time
Heuristics number 1:
Push selections down
Heuristics number 2:
Sometimes push selections up, then down

14. Predicate Pushdown
pname
pname
s price>100 AND city=“Seattle”
maker=name
maker=name
price>100
city=“Seattle”
Product
Company
Product
Company
The earlier we process selections, less tuples we need to manipulate
higher up in the tree (but may cause us to loose an important ordering
of the tuples, if we use indexes).

15. Dynamic Programming Originally proposed in System R
Only handles single block queries:
Heuristics: selections down, projections up
Dynamic programming: join reordering
SELECT list FROM list WHERE cond1 AND cond2 AND AND condk

16. Dynamic Programming Given: a query R1 || R2 || … || Rn
Assume we have a function cost() that gives us the cost of every join tree
Find the best join tree for the query

17. Dynamic Programming
Idea: for each subset of {R1, …, Rn}, compute the best plan for that subset
In increasing order of set cardinality:
Step 1: for {R1}, {R2}, …, {Rn}
Step 2: for {R1,R2}, {R1,R3}, …, {Rn-1, Rn} …
Step n: for {R1, …, Rn}
It is a bottom-up strategy
A subset of {R1, …, Rn} is also called a subquery

18. Dynamic Programming
For each subquery Q {R1, …, Rn} compute the following:
Size(Q)
A best plan for Q: Plan(Q)
The cost of that plan: Cost(Q)

19. Dynamic Programming Step 1: For each {Ri} do: Size({Ri}) = B(Ri)
Plan({Ri}) = Ri
Cost({Ri}) = (cost of scanning Ri)

20. Dynamic Programming
Step i: For each Q {R1, …, Rn} of cardinality i do:
Compute Size(Q) (later…)
For every pair of subqueries Q’, Q’’ s.t. Q = Q’  Q’’ compute cost(Plan(Q’) || Plan(Q’’))
Cost(Q) = the smallest such cost
Plan(Q) = the corresponding plan

21. Dynamic Programming
Return Plan({R1, …, Rn})

22. Dynamic Programming
To illustrate, we will make the following simplifications:
Cost(P1 || P2) = Cost(P1) + Cost(P2) size(intermediate result(s))
Intermediate results:
If P1 = a join, then the size of the intermediate result is size(P1), otherwise the size is 0
Similarly for P2
Cost of a scan = 0

23. Dynamic Programming Example:
Cost(R5 || R7) = (no intermediate results)
Cost((R2 || R1) || R7) = Cost(R2 || R1) + Cost(R7) + size(R2 || R1) = size(R2 || R1)

24. Dynamic Programming Relations: R, S, T, U
Number of tuples: 2000, 5000, 3000, 1000
Size estimation: T(A || B) = 0.01*T(A)*T(B)

25. Subquery
Size
Cost
Plan RS RT RU ST SU TU
RST
RSU
RTU
STU
RSTU

26. Subquery
Size
Cost
Plan RS
100k RT
60k RU
20k ST
150k SU
50k TU
30k
RST 3M
(RT)S
RSU 1M
(RU)S
RTU
0.6M
(RU)T
STU
1.5M
(TU)S
RSTU
30M
60k+50k=110k
(RT)(SU)

27. Reducing the Search Space
Left-linear trees v.s. Bushy trees
Trees without cartesian product
Example: R(A,B) || S(B,C) || T(C,D)
Plan: (R(A,B) || T(C,D)) || S(B,C) has a cartesian product – most query optimizers will not consider it

28. Dynamic Programming: Summary
Handles only join queries:
Selections are pushed down (i.e. early)
Projections are pulled up (i.e. late)
Takes exponential time in general, BUT:
Left linear joins may reduce time
Non-cartesian products may reduce time further

29. Rule-Based Optimizers
Extensible collection of rules
Rule = Algebraic law with a direction
Algorithm for firing these rules
Generate many alternative plans, in some order
Prune by cost
Volcano (later SQL Sever)
Starburst (later DB2)

30. Completing the Physical Query Plan
Choose algorithm to implement each operator
Need to account for more than cost:
How much memory do we have ?
Are the input operand(s) sorted ?
Decide for each intermediate result:
To materialize
To pipeline

31. Optimizations Based on Semijoins
Semi-join based optimizations
R S = P A1,…,An (R S)
Where the schemas are:
Input: R(A1,…An), S(B1,…,Bm)
Output: T(A1,…,An)

32. Optimizations Based on Semijoins
Semijoins: a bit of theory (see [AHV])
Given a conjunctive query:
A full reducer for Q is a program:
Such that no dangling tuples remain in any relation
Q :- R1, R2, . . ., Rn
Ri1 := Ri Rj1
Ri2 := Ri Rj2
Rip := Rip Rjp

33. Optimizations Based on Semijoins
Example:
A full reducer is:
Q :- R1(A,B), R2(B,C), R3(C,D)
R2(B,C) := R2(B,C), R1(A,B)
R3(C,D) := R3(C,D), R2(B,C)
R2(B,C) := R2(B,C), R3(C,D)
R1(A,B) := R1(A,B), R2(B,C)

34. Optimizations Based on Semijoins
Example:
Doesn’t have a full reducer (we can reduce forever)
Theorem a query has a full reducer iff it is “acyclic”
Q :- R1(A,B), R2(B,C), R3(A,C)

35. Optimizations Based on Semijoins
Semijoins in [Chaudhuri’98]
CREATE VIEW DepAvgSal As (
SELECT E.did, Avg(E.Sal) AS avgsal
FROM Emp E
GROUP BY E.did)
SELECT E.eid, E.sal
FROM Emp E, Dept D, DepAvgSal V
WHERE E.did = D.did AND E.did = V.did
AND E.age < 30 AND D.budget > 100k
AND E.sal > V.avgsal

36. Optimizations Based on Semijoins
First idea:
CREATE VIEW LimitedAvgSal As (
SELECT E.did, Avg(E.Sal) AS avgsal
FROM Emp E, Dept D WHERE E.did = D.did AND D.buget > 100k
GROUP BY E.did)
SELECT E.eid, E.sal
FROM Emp E, Dept D, LimitedAvgSal V
WHERE E.did = D.did AND E.did = V.did
AND E.age < 30 AND D.budget > 100k
AND E.sal > V.avgsal

37. Optimizations Based on Semijoins
Better: full reducer
CREATE VIEW PartialResult AS
(SELECT E.id, E.sal, E.did
FROM Emp E, Dept D
WHERE E.did=D.did AND E.age < 30
AND D.budget > 100k)
CREATE VIEW Filter AS
(SELECT DISTINCT P.did FROM PartialResult P)
CREATE VIEW LimitedAvgSal AS
(SELECT E.did, Avg(E.Sal) AS avgsal
FROM Emp E, Filter F
WHERE E.did = F.did GROUP BY E.did)

38. Optimizations Based on Semijoins
SELECT P.eid, P.sal
FROM PartialResult P, LimitedDepAvgSal V
WHERE P.did = V.did AND P.sal > V.avgsal

39. Modern Query Optimizers
Volcano
Rewrite rules
Extensible
Starburst
Keeps query blocks
Interblock, intrablock optimizations

40. Size Estimation RAMAKRISHAN BOOK CHAPT. 15.2
The problem: Given an expression E, compute T(E) and V(E, A)
This is hard without computing E
Will ‘estimate’ them instead

41. Size Estimation Estimating the size of a projection
Easy: T(PL(R)) = T(R)
This is because a projection doesn’t eliminate duplicates

42. Size Estimation Estimating the size of a selection S = sA=c(R)
T(S) san be anything from 0 to T(R) – V(R,A) + 1
Estimate: T(S) = T(R)/V(R,A)
When V(R,A) is not available, estimate T(S) = T(R)/10
S = sA<c(R)
T(S) can be anything from 0 to T(R)
Estimate: T(S) = (c - Low(R, A))/(High(R,A) - Low(R,A))
When Low, High unavailable, estimate T(S) = T(R)/3

43. Size Estimation Estimating the size of a natural join, R ||A S
When the set of A values are disjoint, then T(R ||A S) = 0
When A is a key in S and a foreign key in R, then T(R ||A S) = T(R)
When A has a unique value, the same in R and S, then T(R ||A S) = T(R) T(S)

44. Size Estimation Assumptions:
Containment of values: if V(R,A) <= V(S,A), then the set of A values of R is included in the set of A values of S
Note: this indeed holds when A is a foreign key in R, and a key in S
Preservation of values: for any other attribute B, V(R || A S, B) = V(R, B) (or V(S, B))

45. Size Estimation Assume V(R,A) <= V(S,A)
Then each tuple t in R joins some tuple(s) in S
How many ?
On average T(S)/V(S,A)
t will contribute T(S)/V(S,A) tuples in R ||A S
Hence T(R ||A S) = T(R) T(S) / V(S,A)
In general: T(R ||A S) = T(R) T(S) / max(V(R,A),V(S,A))

46. Size Estimation Example: T(R) = 10000, T(S) = 20000
V(R,A) = 100, V(S,A) = 200
How large is R || A S ?
Answer: T(R ||A S) = /200 = 1M

47. Histograms Statistics on data maintained by the RDBMS
Makes size estimation much more accurate (hence, cost estimations are more accurate)

48. Histograms Employee(ssn, name, salary, phone)
Maintain a histogram on salary:
T(Employee) = 25000, but now we know the distribution
Salary:
0..20k
20k..40k
40k..60k
60k..80k
80k..100k
> 100k
Tuples
200
800
5000
12000
6500
500

49. Histograms Eqwidth Eqdepth 0..20 20..40 40..60 60..80 80..100 2 104
9739
152 3
0..44
44..48
48..50
50..56
2000

50. The Independence Assumption
SELECT *
FROM R
WHERE R.Age = ‘35’ and R.City = ‘Seattle’
Histogram on Age tells us that fraction p1 have age 35
p1 |R|
p2 |R|
Histogram on City tells us that fraction p2 live in Seattle
p1 p2 |R|
Lacking more information, use independence:

51. Correlated Attributes
A better idea is to use a 2-dimensional histogram
Generalize: k-dimensional
But this uses too much space
Getoor paper: find “conditionally independent attributes”
Goal: several 2 or 3 dimensional histograms “capture” a high dimensional histogram