1. Query Processing and Query Optimization Database System Implementation CSE 507 Some slides adapted from Silberschatz, Korth and Sudarshan Database System Concepts – 6 th Edition. And Elamsri and Navathe, Fundamentals of Database Systems – 6 th Edition.

2. Basic Steps in Query Processing 1.Parsing and translation 2.Optimization 3.Evaluation

3. Basic Steps in Query Processing Contd. Material adapted from Silberchatz, Korth and Sudarshan  Parsing and translation  translate the query into its internal form, e.g., relational algebra.  Parser checks syntax, verifies relations  Evaluation  The query-execution engine takes a query-evaluation plan, executes that plan, and returns the answers to the query.

4. Basic Steps: Regarding Optimization (1/3) Material adapted from Silberchatz, Korth and Sudarshan  A relational algebra expression may have many equivalent expressions  E.g., for “Select salary from Instructor where salary < 75000”  salary  75000 (  salary (instructor)) is equivalent to  salary (  salary  75000 (instructor))  For each relational algebra operation we have candidate algorithms  Thus, a relational-algebra expression can be evaluated in many ways.

5. Basic Steps: Regarding Optimization (2/3) Material adapted from Silberchatz, Korth and Sudarshan  Annotated expression specifying detailed evaluation strategy is called an evaluation-plan.  E.g., can use an index on salary to find instructors with salary < 75000,  or can perform complete relation scan and discard instructors with salary  75000

6. Basic Steps: Regarding Optimization (3/3) Material adapted from Silberchatz, Korth and Sudarshan Query Optimization : Amongst all equivalent evaluation plans choose the one with lowest cost.  Cost is estimated using statistical information from the database catalog  e.g. number of tuples in each relation, size of tuples, etc.

7. Measures of Query Cost Material adapted from Silberchatz, Korth and Sudarshan  Total Cost = total elapsed time for answering query Many factors contribute to time cost e.g., disk accesses, CPU, or even network communication  Typically disk access is the predominant cost, and is also relatively easy to estimate. Measured by taking into account Number of seeks X average-seek-cost Number of blocks read X average-block-read-cost Number of blocks written X average-block-write-cost

8. Measures of Query Cost Material adapted from Silberchatz, Korth and Sudarshan  Some simplifying assumptions will make Average-block-read-cost == Average-block-write-cost  Also we will mostly work with total #blocks accessed as the total cost of a query algorithm.

9. Measures of Query Cost Material adapted from Silberchatz, Korth and Sudarshan  Occasionally, we use the number of block transfers from disk and the number of seeks as the cost measures t T – time to transfer one block t S – time for one seek Cost for b block transfers plus S seeks b * t T + S * t S

10. Query Processing Algorithms

11. Selection Operation  File scan  Algorithm A1 ( linear search ). Scan each file block and test all records to see whether they satisfy the selection condition.  Cost estimate = b r block transfers + 1 seek  b r denotes #blocks containing records from relation r  If selection is on a key attribute, can stop on finding record  cost = ( b r /2) block transfers + 1 seek

12. Selection Operation  Index scan – search algorithms that use an index  selection condition must be on search-key of index.  A2 ( primary index, equality on key ). Retrieve a single record that satisfies the corresponding equality condition  #blocks accessed = height + 1  Cost = (height + 1) X (t T + t S )  A3 ( primary index, equality on nonkey ) Retrieve multiple records.  Records will be on consecutive blocks  Let b = #blocks containing matching records  Cost = height X (t T + t S ) + t S + t T X b; total blocks = height + b ;

13. Selection Operation  A4 ( secondary index ).  Retrieve a single record if the search-key is a candidate key  Total #blocks accessed = height + 1  Cost = (height + 1) * (t T + t S )  Retrieve multiple records if search-key is not a candidate key  Each of n matching records may be on a different block  Total #blocks accessed = height + n + 1  Cost = (height + n + 1) * (t T + t S )

14. External Sorting Algorithm  N-way Sort-Merge strategy :  Starts by sorting small subfiles ( runs ) of the main file  Then merges the sorted runs, creating larger sorted subfiles that are merged in turn.  Each merge phase merges >= 2 runs.

15. External Sorting Algorithm Example 2-way

16. Cost of External Sorting Algorithm  n R : number of initial runs;  b : number of file blocks;  n B : available buffer space;  d M : degree of merging;  n P : number of passes. Sorting phase: n R =  (b/n B )  Merging phase: d M = Min (n B -1, n R ); n P =  (log dM (n R ))  Total #blocks accessed = 2*b + (2*b* (log dM (n R ))

17. Join Operation: Nested Loop Join  To compute the theta join R  S for each tuple t r in R do begin for each tuple t s in S do begin test pair (t r,t s ) to see if they satisfy the join condition  if they do, add t r t s to the result. end end  R is called the outer relation and S the inner relation of the join.  Requires no indices and can be used with any kind of join condition.  Expensive since it examines every pair of tuples in the two relations ??

18. Join Operation: Nested Loop Join  In the worst case, if there is enough memory only to hold one block of each relation, the estimated cost is n r  b s + b r blocks transferred, plus n r + b r seeks  If the smaller relation fits entirely in memory, use that as the inner relation.  Reduces cost to b r + b s block transfers and 2 seeks  Block nested-loops algorithm (next slide) is preferable.

19. Join Operation: Nested Loop Join with blocks  Variant of nested-loop join in which every block of inner relation is paired with every block of outer relation. for each block B r of r do begin for each block B s of s do begin for each tuple t r in B r do begin for each tuple t s in B s do begin Check if (t r,t s ) satisfy the join condition if they do, add t r t s to the result. end end end end

20. Nested Loop Join using blocks  Worst case estimate: b r  b s + b r block transfers + 2 * b r seeks  Each block in the inner relation S is read once for each block in the outer relation  Best case: b r + b s block transfers + 2 seeks.  If n B buffers are available then:  In block nested-loop, use n B — 2 disk blocks as blocking unit for outer relations; use remaining two blocks to buffer inner relation and output  Cost =  b r / ( n B — 2 )   b s + b r block transfers + 2  b r / ( n B — 2 )  seeks

21. Join Operation: Single Loop Join  For each tuple t R in the outer relation R,  use the index to look up tuples in S that satisfy the join condition with tuple t R.  If buffer has space for only one page of R.  Cost of the join if we have a secondary index on S b R + |R|  (height + 1 + s B ) block accesses  s B is the selection cardinality for the join attribute.

22. Join Operation: Single Loop Join Cost of the join if we have a clustering index on S b R + |R|  (height + s B / Bfr-of-S) block accesses s B is the selection cardinality for the join attribute. Cost of the join if we have a primary index on S b R + |R|  (height + 1) block accesses

23. Join Operation: Merge Join Algorithm 1.Sort both relations on their join attribute (if not already sorted on the join attributes). 2.Merge the sorted relations to join them 1.Join step is similar to the merge stage of the sort-merge algorithm. 2.Main difference is handling of duplicate values in join attribute — every pair with same value on join attribute must be matched and reported in the result.

24. Join Operation: Merge Join Algorithm  Each block needs to be read only once.  Under the assumption that all tuples of one relation for any given value of the join attributes fit in memory  If b b is the number buffer blocks allocated to each relation.  The cost of merge join is: b r + b s block transfers +  b r / b b  +  b s / b b  seeks + the cost of sorting if relations are unsorted.

25. Join Operation: Hash Join Algorithm Step 1: Partition Phase: h maps JoinAttrs values to {0, 1,..., n}, where JoinAttrs denotes the common attributes of r and s used in the join.  r 0, r 1,..., r n denote partitions of R’s tuples  Each tuple t r  R is put in partition r i where i = h(t r [JoinAttrs]).  s 0,, s 1..., s n denotes partitions of S’s tuples  Each tuple t s  S is put in partition s i, where i = h(t s [JoinAttrs]).  Each partition (of S or R) may spread across several disk blocks.

26. Join Operation: Hash Join Algorithm Intuition of Partition Phase:  R tuples in r i need only to be compared with S tuples in s i  Need not be compared with s tuples in any other partition, since:  an r tuple and an s tuple that satisfy the join condition will have the same value for the join attributes.  If that value is hashed to some value i, the r tuple has to be in r i and the s tuple in s i.

27. Join Operation: Hash Join Algorithm Step 1(a). Partition the relation S using hashing function h. Step 1(b). Partition R similarly. For each i: (Making s i as the build relation) (a)Load s i into memory and build an in-memory hash index on it using the join attribute. This hash index uses a different hash function than the earlier one h. (b)Read the tuples in r i from the disk one by one. For each tuple t r locate each matching tuple t s in s i using the in-memory hash index. Output the join result. Step 2 Probe Phase: Step 1: Partition Phase:

28. Illustrating Hash Join Algorithm

29. Some Details on Hash Join Algorithm  The value n (#partitions) and the hash function h is chosen such that each s i should fit in memory.  If we have space for M blocks in the Main Mem then, n must be at least  b s /M .  To be more precise, we need to account for space for  One block for reading in r i + 1 output buffer + index on s i  The probe relation (relation R ) partitions r i need not fit in memory.  We will just take one block from r i each time.

30. Some Details Hash Join Algorithm Recursive partitioning  Required if #partitions n is greater than #buffers M available.  Instead of partitioning n ways, use M – 1 partitions.  Further partition the M – 1 partitions using a different hash function  Use same partitioning method on both R and S.

31. Join Operation: Hash Join Algorithm  Hash-table overflow occurs in partition s i if s i does not fit in memory. Reasons could be  Many tuples in S with same value for join attributes  Bad hash function  Overflow resolution can be done in build phase  Partition s i is further partitioned using different hash function.  Partition r i must be similarly partitioned.

32. Join Operation: Hash Join Algorithm  Overflow avoidance performs partitioning carefully to avoid overflows during build phase  E.g. partition build relation into many partitions, then combine them  Both approaches fail with large numbers of duplicates  Fallback option: use block nested loops join on overflowed partitions.

33. Join Operation: Hash Join Algorithm Cost If recursive partitioning is not required: cost of hash join is 3( b r + b s ) + 4  n block transfers

34. Join Operation: Hash Join Algorithm Cost If recursive partitioning is not required: cost of hash join is 3( b r + b s ) + 4  n block transfers Small, can be ignored!

35. Join Operation: Hybrid Hash Join Algorithm  Useful when memory sized are relatively large, and the build input is bigger than memory.  Main feature of hybrid hash join: Keep the first partition of the build relation in memory.

36. Some Meta-Level Evaluation Strategies

37. Materialization Materialized evaluation:  Evaluate one operation at a time, starting at the lowest- level.  Use intermediate results materialized into temporary relations to evaluate next-level operations.

38. Materialization Consider the following example query and its expression tree. Select name from department natural join instructor where department.building = “Watson”;

39. Materialization Example, in figure below, compute and store then compute the store its join with instructor, and finally compute the projection on name.

40. Materialization Contd..  Materialized evaluation is always applicable  Cost of writing results to disk and reading them back can be quite high  Our cost formulas for operations for far have ignored cost of writing results to disk, so  Overall cost = Sum of costs of individual operations + cost of writing intermediate results to disk

41. Pipelining Pipelined evaluation :  Evaluate several operations simultaneously, passing the results of one operation on to the next.  E.g., in previous expression tree, don’t store result of  instead, pass tuples directly to the join.  Similarly, don’t store result of join, pass tuples directly to projection.  Any thoughts on its applicability? Can it be used for processing all algorithms.

42. Pipelining  Much cheaper than materialization: no need to store a temporary relation to disk.  Pipelining may not always be possible – e.g., sort, hash-join.  For pipelining to be effective, use evaluation algorithms that generate output tuples even as tuples are received for inputs to the operation.  Pipelines can be executed in two ways: demand driven and producer driven

43. Pipelining: Demand Driven  In demand driven or lazy evaluation  System repeatedly requests next tuple from top level operation  Each operation requests next tuple from children operations as required, in order to output its next tuple  In between calls, operation has to maintain “ state ” so it knows what to return next

44. Pipelining: Producer Driven  In producer-driven or eager pipelining  Operators produce tuples eagerly and pass them up to their parents  Buffer maintained between operators, child puts tuples in buffer, parent removes tuples from buffer  if buffer is full, child waits till there is space in the buffer, and then generates more tuples  System schedules operations that have space in output buffer and can process more input tuples