Access Path Selection in a Relation Database Management System (summarized in section 2)

Processing an SQL statement parsing, optimization, code generation, execution an SQL statement may have many query blocks (nesting)

Optimizer validates parsed query collects statistics on referenced relations & columns discovers available access paths for each relation checks for type errors in expressions Access path selection: –determines order of evaluation of query blocks –a tree of alternate path choices is created for each query block with more than one relation –minimum cost access path is chosen from the tree results of optimizer is passed to code generation and execution components

RSS (Research Storage System) storage manager for System R Maintains physical storage, access paths, locking, logging, and recovery Relations are stored as a collection of tuples tuples are stored on 4K pages; pages are organized into segments segments completely contain one or more relations tuples are accessed via a scan: sequential scan or index scan indexes are B-trees with linked leaves sequential scan touches all the pages of a segment that contains a relation once index scans touch all the leaf pages of the index once; relation pages >=1 times if index and data tuples are in the same order, the data is “clustered” scans may takes a set of predicates to apply to a tuple before returning it –predicates are of the form (column op value)

Cost computation cost = page fetches + W*(RSI calls) –cost = IO costs + W * CPU costs an index that matches a boolean factor of the query is an efficient access path

Statistics NCARD(T): cardinality of the relation T TCARD(T): number of pages used for T P(T): fraction of pages in a segment used for T ICARD(I): number of distinct keys in index I NINDX(I): number of pages in index I

Selectivity column = value : F = 1/ICARD(column) if there is an index. F = 1/10 otherwise column1 = column2: F = 1/MAX(ICARD(column1), ICARD(column2)); F = 1/ICARD(column i); F = 1/10 column > value: F = (high key value - value) / (high key - low key) column between value1 and value2: F= (value2 - value1)/ (high key - low key) column IN (list of values): F = (# of items in list) * (selectivity for column = value) max is 1/2 columnA IN subquery: F = (card. of subquery) / (  card. of subquery relations) (pred1) OR (pred2): F = F(pred1) + F(pred2) - F(pred1) * F(pred2) (pred1) AND (pred2): F = F(pred1) * F(pred2) NOT pred: F = 1 - F(pred)

QCARD QCARD is (  card. of all relations) * (  F(pred i)) RSICARD is the expected number of calls to RSI (  card. of all relations) * (  F(sargable pred i)) An “interesting order” is an order specified by the GROUP BY or ORDER BY clause Single relation cost: cheapest access path which produces the “interesting order” or cheapest access path plus sorting cost of result

Cost Table (p. 515) index pages fetched plus data pages fetched plus W times RSI tuple retrieval calls. unique index matching an equal predicate: 1+1+W clustered index I matching one or more boolean factors: F(preds) *(NINDX(I) + TCARD) + W * RSICARD etc…

Joins nested loops and merging scans merging scans require sorts on the join column -- another “interesting order” n-way joins can be done by a succession of 2-way joins; not necessarily using the same technique. Results may be pipelined if a sort is not required.

Join ordering n! permutations of relation join orders join of (k+1) relation with previous k relations is independent of first k join order avoid Cartesian products when possible; make them as late as possible

Construct a tree construct a tree of possible join orderings: keep the cheapest order that produces an interesting ordering. First find the best way to access each single relation for each interesting ordering and unordered. Next, find the best way of joining any relation to each of these. Repeat until all relations have been added to each branch Choose the cheapest strategy that has an interesting ordering, or the cheapest strategy plus a sort. Total number of solutions to store: 2 n