Single table optimization

 

At run time, the optimizer chooses an optimal access method for the query by calculating an implementation cost based on the current state of the database. The optimizer uses 2 costs when making decisions: an I/O cost and a CPU cost. The goal of the optimizer is to minimize both I/O and CPU cost.

 

Optimizing Access to each table

The optimizer uses a general set of guidelines to choose the best method for accessing data of each table. The optimizer:

• Determines the default filter factor for each predicate in the selection clause.

• Determines the true filter factor of the predicates by doing a key range estimate when the selection predicates match the left most keys of an index or by using columns statistic when available.

• Determines the cost of table scan processing if an index is not required.

• Determines the cost of creating an index over a table if an index is required. This index is created by performing either a table scan or creating an index-from-index.

• Determines the cost of using a sort routine or hashing method if appropriate.

• Determines the cost of using existing indexes using Index Probe or Index Scan

  • Orders the indexes. For SQE, the indexes are ordered in general such that the indexes that access the smallest number of entries are examined first. For CQE, the indexes are generally ordered from mostly recently created to oldest.

  • For each index available, the optimizer does the following:

    • Determines if the index meets the selection criteria.

    • Determines the cost of using the index by estimating the number of I/Os and the CPU cost that will be needed to perform the Index Probe or the Index Scan and the possible Table Probes.

    • Compares the cost of using this index with the previous cost (current best).

    • Picks the cheaper one.

    • Continues to search for best index until the optimizer decides to look at no more indexes.

    For SQE, since the indexes are ordered so that the best indexes are examined first, once an index that is more expensive than the previously chosen best index, the search is ended.

    For CQE, the time limit controls how much time the optimizer spends choosing an implementation. It is based on how much time was spent so far and the current best implementation cost found. The idea is to prevent the optimizer from spending more time optimizing the query than it takes to actually execute the query. Dynamic SQL queries are subject to the optimizer time restrictions. Static SQL queries optimization time is not limited. For OPNQRYF, if you specify OPTALLAP(*YES), the optimization time is not limited. For small tables, the query optimizer spends little time in query optimization. For large tables, the query optimizer considers more indexes. Generally, the optimizer considers five or six indexes (for each table of a join) before running out of optimization time. Because of this, it is normal for the optimizer to spend longer lengths of time analyzing queries against larger tables.

• Determines the cost of using a temporary bitmap

  • Orders the indexes that can be used for bitmapping. In general the indexes that select the smallest number of entries are examined first.

  • Determine the cost of using this index for bitmapping and the cost of merging this bitmap with any previously generated bitmaps.

  • If the cost of this bitmap plan is cheaper than the previous bitmap plan, continue searching for bitmap plans.

• After examining the possible methods of access the data for the table, the optimizer chooses the best plan from all the plans examined.

 

Parent topic:

Processing queries: Overview