Catalog Information Used in Cost Functions
To estimate the costs of various execution strategies, we must keep track of any information that is needed for the cost functions. This information may be stored in the DBMS catalog, where it is accessed by the query optimizer. First, we must know the size of each file. For a file whose records are all of the same type, the number of records (tuples) (r), the (average) record size (R), and the number of file blocks (b) (or close estimates of them) are needed. The blocking factor (bfr) for the file may also be needed. We must also keep track of the primary file organization for each file. The primary file organization records may be unordered, ordered by an attribute with or without a primary or clustering index, or hashed (static hashing or one of the dynamic hashing methods) on a key attribute. Information is also kept on all primary, secondary, or clustering indexes and their indexing attributes. The number of levels (x) of each multilevel index (primary, secondary, or clustering) is needed for cost functions that estimate the number of block accesses that occur during query execution. In some cost functions the number of first-level index blocks (bI1) is needed.
Another important parameter is the number of distinct values (d) of an attribute and the attribute selectivity (sl), which is the fraction of records satisfying an equality condition on the attribute. This allows estimation of the selection cardinality (s sl * r) of an attribute, which is the average number of records that will satisfy an equality selection condition on that attribute. For a key attribute, d = r, sl = 1/r and s = 1. For a nonkey attribute, by making an assumption that the d distinct values are uniformly distributed among the records, we estimate sl = (1/d) and so s = (r/d).
Information such as the number of index levels
is easy to maintain because it does not change very often. However, other
information may change frequently; for example, the number of records r in a file changes every time a record
is inserted or deleted. The query optimizer will need reasonably close but not
necessarily com-pletely up-to-the-minute values of these parameters for use in
estimating the cost of various execution strategies.
For a nonkey attribute with d distinct values, it is often the case
that the records are not uniformly distributed among these values. For example,
suppose that a company has 5 departments numbered 1 through 5, and 200
employees who are distributed among the departments as follows: (1, 5), (2,
25), (3, 70), (4, 40), (5, 60). In such cases, the optimizer can store a histogram that reflects the
distribution of employee records over different departments in a table with the
two attributes (Dno, Selectivity), which would contain the following values for
our example: (1, 0.025), (2, 0.125), (3, 0.35), (4, 0.2), (5, 0.3). The
selectivity values stored in the histogram can also be estimates if the
employee table changes frequently.
In the next two sections we examine how some of
these parameters are used in cost functions for a cost-based query optimizer.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.