1. Relational Query Optimization
Chapter 15
The slides for this text are organized into chapters. This lecture covers Chapter 15, and discusses relational query optimization in depth.
It should be covered after Chapter 8, which provides an overview of storage and indexing. At the instructor’s discretion, it can also be omitted without loss of continuity in other parts of the text. (In particular, Chapter 20 can be covered without covering this chapter, though this material gives more insight into the workings of a DBMS.)
This chapter is most appropriate for a course with an implementation emphasis, and is a candidate for omission in a course with an applications emphasis. 1

2. Query Evaluation
SQL queries are translated into an extended form of relational algebra:
Query Plan Reasoning:
Tree of ops,
with choice of one among several algorithms for each operator
Query Plan Execution:
Each operator implemented using `pull’ interface: when operator is `pulled’ for next output tuples, it `pulls’ on its inputs and computes them. 2

3. Overview of Query Evaluation
Query Plan Optimization :
Ideally: Want to find best plan. Practically: Avoid worst plans!
Two main issues in query optimization:
For a given query, what plans are considered?
Algorithm to search plan space for cheapest (estimated) plan.
How is the cost of a plan estimated?
Cost Models based on I/O estimates 2

4. Physical Query Plan An extended relational algebra tree
Annotations at each node indicating access methods to use for each table
The implementation methods used for each relational operator.
Costs estimated per operator.
Reserves
Sailors
sid=sid
bid=100
rating > 5
sname
(Simple Nested Loops)
(On-the-fly)
Reserves
Sailors
sid=sid
bid=100
rating > 5
sname

5. Schema for Examples Similar to old schema; rname added for variations.
Sailors (sid: integer, sname: string, rating: integer, age: real)
Reserves (sid: integer, bid: integer, day: dates, rname: string)
Similar to old schema; rname added for variations.
Reserves:
Each tuple is 40 bytes long, 100 tuples per page, 1000 pages.
Sailors:
Each tuple is 50 bytes long, 80 tuples per page, 500 pages. 3

6. Query Blocks: Units of Optimization
An SQL query is parsed into a collection of query blocks.
An SQL query with no nesting and exactly one SELECT,FROM,WHERE, GROUP BY, HAVING clause.
WHERE is in conjunctive normal form.
Nested blocks are usually treated as calls to a subroutine, made once per outer tuple.
Optimizing one block at a time.
SELECT S.sname
FROM Sailors S
WHERE S.age IN
Reference to nested block
SELECT S.sname
FROM Sailors S
WHERE S.age IN
(SELECT MAX (S2.age)
FROM Sailors S2
GROUP BY S2.rating)
SELECT MAX (S2.age)
FROM Sailors S2
GROUP BY S2.rating
Outer block
Nested block 7

7. Query Block For each block, the plans considered are:
All available access methods, for each relation in FROM clause.
All left-deep join trees
i.e., all ways to join the relations one-at-a-time, with the inner relation in the FROM clause, considering all relation permutations and join methods.
MAX(S2.age) (Group By S2.rating( S2.age(Sailors)))

8. Cost Estimation For each plan considered, must estimate cost:
Must estimate cost of each operation in plan tree.
Depends on input cardinalities.
Depends on algorithm (sequential scan, index scan).
Must also estimate size of result for each operation.
Use information about the input relations.
For selections and joins, assume independence of predicates.
Must make assumptions about effect of predicates.
Cost of plan = sum of cost of each operator in tree. 8

9. Cost Estimation product of cardinalities of involved relations (FROM)
Result size =
product of cardinalities of involved relations (FROM) *
product of reduction factors (WHERE). 8

10. Size Estimation and Reduction Factors
SELECT attribute list
FROM relation list
WHERE term1 AND ... AND termk
Consider a query block:
Maximum # tuples in result is product of cardinalities of relations in FROM clause.
Reduction factor (RF) associated with each term reflects impact of term in reducing result size.
Result cardinality = Max #tuples * product of all RF’s.
Implicit assumption that terms are independent! 9

11. Reduction Factors
SELECT attribute list
FROM relation list
WHERE term1 AND ... AND termk
Reduction factor (RF) associated with each term reflects impact of term in reducing result size:
Term col=value has RF ?
Term col1=col2 has RF?
Term col>value has RF? 9

12. Cost of a Plan (cont') Reduction Factor.
Column = value Given index I on column, assume uniform distribution. 1/Nkeys(I). - Otherwise, fixed reduction factor 1/10
Column1 = column2 - Given indexes I1 and I2 on column1 and column2, assuming each key value in I1 (smaller one) has a matching value in I2. 1/MAX(Nkeys(I1), Nkeys(I2)). - One index I, 1/Nkeys(I) - otherwise, 1/10
Column > values - Given an index I on column, arithmetic type. High(I) – value / High(I) – Low(I). - Not arithmetic type, or no index. A fraction Less than half is arbitrarily chosen.
Column IN (list of values) - reduction factor for (column = value) * number of items in the list.
Assumptions for reduction factors:
Uniform distribution of values
Independent distribution of values in different columns.

13. Cost of a Plan (cont) Improved Statistics: Histograms
Uniform distribution is not accurate since real data is not uniformly distributed.
Histogram: data structure maintained by DBMS to approximate data distribution.
Equiwidth: divide range of column values into subranges (buckets). Assuming distribution within histogram bucket is uniform.
Equidepth: number of tuples within each bucket is equal (almost).
Compressed equidepth: maintain separate counts for small number of very frequent values, and maintain equidepth histogram to cover remaining values.
5.0
5.0
5.0
9.0
Equiwidth
Equidepth
2.67
2.25
2.5
1.33
1.0
1.75
Bucket
Count
Bucket
Count

14. Relational Algebra Equivalences
Allow to choose different join orders and to `push’ selections and projections ahead of joins.
Selections: (Cascade)
Combine several selections into one selection. Evaluate the conjunctive condition to each of the tuple.
Separate conjunctions into smaller selection operations, Able to combine as Join.
(Commute)
Projections:
(Cascade)
Where ai  ai+1 for i =1…n-1. 10

15. Relational Algebra Equivalences
(Associative)
Joins:
R (S T) (R S) T
(Commute)
(R S) (S R)
Show that:
R (S T) (T R) S
When joining several relations, we are free to join the relations in any order we choose.

16. Selects, Projects and Joins
Case1: a (c(R))  c (a(R))
A projection commutes with a selection that only uses attributes retained by the projection.
XCase2: R c S  c (RS)
Combine a selection with a cross-product to form a join.
Case3: i.e., (R S) (R) S
A selection on just attributes of R commutes with Join. 11

17. Selects, Projects and Joins
In general, part of the selection condition can be pushed ahead of the Join.
c1c2 c3 (R S)  c1(c2 (R) c3 (S))
Project a (RS)  a1 (R)  a2 (S) a (R c S)  a1 (R) c a2 (S) (Where c appears in a)

18. Enumeration of Alternative Plans
There are two main cases:
Single-relation plans
Multiple-relation plans 12

19. Single Relation Plans
Queries over a single relation: combination of selects, projects, and aggregate operations:
Main decision: which access path to use in retrieving tuples.
Most selective access path (file scan / index) if only single operator considered.
Different operations are essentially carried out together.
e.g., if an index is used for a selection, projection is done for each retrieved tuple, and the resulting tuples are pipelined into the aggregate computation. 12

20. Single Relation Plans without Index
SELECT S.rating, COUNT(*)
FROM Sailors S
WHERE S.rating > 5 AND S.age = 20
GROUP BY S.rating
HAVING COUNT DISTINCT (S.sname) > 2
 s.rating, COUNT(*)( HAVING COUNT DISTINCT(S.sname) > 2( GROUP Bys.rating( s.rating, S.sname (  s.rating>5  S.age=20 ( Sailors)))))
A file scan to retrieve tuples and apply selections and projections.
Writing out tuples after the selections and projections.
Sorting these tuples to implement GROUP BY clause.
* Note: GROUP BY and HAVING are done on-the-fly.
e.g., Cost = Cost1(scan) + cost2 (writing <S.rating, S.sname> pairs) cost3 (sorting as per the GROUP BY clause) Sailors = 500 pages cost1 = 500, cost3 = 3*Npages = 60 (assuming two passes)
cost2 = 500* ratio of tuple size * RFs = ratio of tuple size = pair size / tuple size = 0.8
RF(s.rating>5) = RF(S.age=20) = 0.1

21. Single-Relation Plans with Index
Single-index access path
When several indexes match the selection conditions, choose the most selective access path.
Multiple-index access path
Several indexes using Alternatives (2) or (3) for data entries match the selection condition.
Retrieve rids using them individually.
Intersect result set. Sort by page id.
Sorted-index access path
Grouping attributes is a prefix of a tree index.
Using index to retrieve tuples in the order required by GROUP BY clause.
Index-only access path
All attributes mentioned in the query are included in the search key for some dense index on the relation in the FROM clause.
Index-only scan to compute the answer.

22. Single-Relation Plans with Index
Index I on primary key matches selection:
Cost is Height(I)+1 for a B+ tree, about 1.2 for hash index.
Clustered index I matching one or more selects:
(NPages(I)+NPages(R)) * product of RF’s of matching selects.
Non-clustered index I matching one or more selects:
(NPages(I)+NTuples(R)) * product of RF’s of matching selects.
Sequential scan of file:
NPages(R).
Note: Typically, no duplicate elimination on projections! (Exception: Done on answers if user says DISTINCT.) 13

23. Example Sailors: 500 pages, 80 tuples/page Case2: index on rating.
SELECT S.sid
FROM Sailors S
WHERE S.rating=8
Sailors: 500 pages, 80 tuples/page
Case2: index on rating.
Clustered index: (1/NKeys(I)) * (NPages(I)+NPages(S)) = (1/10) * (50+500) pages Unclustered index: (1/NKeys(I)) * (NPages(I)+NTuples(S)) = (1/10) * ( ) pages
Case3: index on sid.
Would have to retrieve all tuples/pages. With a clustered index, the cost is , with unclustered index,
Case4: file scan:
We retrieve all file pages (500). 14

24. Queries Over Multiple Relations
Fundamental decision in System R: only left-deep join trees are considered.
As the number of joins increases, the number of alternative plans grows rapidly; we need to restrict 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). C D B A B A C D 15

25. Enumeration of Left-Deep Plans
Left-deep plans differ only in the order of relations, the access method for each relation, and the join method for each join.
Enumerated using N passes (if N relations joined):
Pass 1: Find best 1-relation plan for each relation.
Pass 2: Find best way to join result of each 1-relation plan (as outer) to another relation. (All 2-relation plans.)
Pass N: Find best way to join result of a (N-1)-relation plan (as outer) to the N’th relation. (All N-relation plans.)
For each subset of relations, retain only:
Cheapest plan overall, plus
Cheapest plan for each interesting order of tuples.
Pass 1 A B C D
Pass 2
Pass 3 16

26. Enumeration of Left-Deep Plans (contd.)
Pass1: 1 relation plan.
Identify selection terms in the WHERE clause that mention only attributes of A. (perform first access of A, before Join)
Identify attributes of A not mentioned in SELECT or WHERE clause (Project out when first access of A, before Join)
Cheapest plan keeping order.
E.g., a file scan (as cheapest overall plan for fetching all tuples) and a B+ tree index (as the cheapest plan for fetching all tuples in the search key order).

27. Enumeration of Left-Deep Plans (contd.)
Pass 2: All 2-relational Plans.
Each of the single-relation plan from Pass 1 as the outer relation, and every other relation as the inner relation.
Examine WHERE clauses:
Selections involving only attributes of inner relation (apply before Join).
Selections defining the Join.
Selections involving attributes of other relations (apply after Join).
Actually, only selections that are really applied before the join are those that match the chosen access paths for A and B.
Depending on Join algorithm chosen, the cost may include the materializing the outer relation.

28. Enumeration of Plans (Contd.)
ORDER BY, GROUP BY, aggregates etc. handled as a final step, using either an `interestingly ordered’ plan or an additional sorting operator.
An N-1 way plan is not combined with an additional relation unless there is a join condition between them, unless all predicates in WHERE have been used up.
i.e., avoid Cartesian products if possible.
In spite of pruning plan space, this approach is still exponential in the # of tables. 16

29. Example Pass 2: each plan retained from Pass 1 as the outer.
Sailors:
B+ tree on rating
Hash on sid
Reserves:
B+ tree on bid
Reserves
Sailors
sid=sid
bid=100
rating > 5
sname
Example
Pass1:
Sailors:
Choice1: B+ tree matches rating>5, probably cheapest.
if selection is expected to retrieve a lot of tuples, and index is unclustered, file scan may be cheaper.
Decision: B+ tree plan kept (because tuples are in rating order).
Reserves: B+ tree on bid matches bid=500; cheapest.
Pass 2:
each plan retained from Pass 1 as the outer.
how to join it with the (only) other relation. e.g., Reserves as outer : Hash index can be used to get Sailors tuples
that satisfy sid = outer tuple’s sid value. 17

30. Nested Queries (SELECT * FROM Reserves R WHERE R.bid=103
SELECT S.sname
FROM Sailors S
WHERE EXISTS
(SELECT *
FROM Reserves R
WHERE R.bid=103
AND R.sid=S.sid)
Nested Queries
Nested block is optimized independently, with the outer tuple considered as providing a selection condition.
Outer block is optimized with the cost of `calling’ nested block computation taken into account.
Implicit ordering of these blocks means that some good strategies are not considered.
The non-nested version of the query is typically optimized better.
Nested block to optimize:
SELECT *
FROM Reserves R
WHERE R.bid=103
AND S.sid= outer value
Equivalent non-nested query:
SELECT S.sname
FROM Sailors S, Reserves R
WHERE S.sid=R.sid
AND R.bid=103 18

31. Highlights of System R Optimizer
Impact:
Most widely used currently; works well for < 10 joins.
Cost estimation:
Statistics, maintained in system catalogs, used to estimate cost of operations and result sizes.
Considers combination of CPU and I/O costs.
Plan Space:
Only the space of left-deep plans is considered.
Left-deep plans allow output of each operator to be pipelined into the next operator without storing it in a temporary relation.
Focus on optimizing SQLs without nesting. No duplication in projections. (unless DISTINCT used)
Cartesian products avoided. 2

32. Other Approaches to Query Optimization
Exclusive search is not suitable for large number of Joins.
Rule-based optimizers: a set of rules to guide the generation of candidate plans.
Randomized plan generation: probabilistic algorithms to explore a large space of plans.

33. Summary Query optimization is an important task in a relational DBMS.
Must understand optimization in order to understand the performance impact of a given database design (relations, indexes) on a workload (set of queries).
Two parts to optimizing a query:
Consider a set of alternative plans.
Must prune search space; typically, left-deep plans only.
Must estimate cost of each plan that is considered.
Must estimate size of result and cost for each plan node.
Key issues: Statistics, indexes, operator implementations. 19

34. Summary Single-relation queries: Multiple-relation queries:
All access paths considered, cheapest is chosen.
Issues: Selections that match index, whether index key has all needed fields and/or provides tuples in a desired order.
Multiple-relation queries:
All single-relation plans are first enumerated.
Selections/projections considered as early as possible.
Next, for each 1-relation plan, all ways of joining another relation (as inner) are considered.
Next, for each 2-relation plan that is `retained’, all ways of joining another relation (as inner) are considered, etc.
At each level, for each subset of relations, only best plan for each interesting order of tuples is `retained’. 20