Optimizer decision-making rules

Optimizer does the following:

• Determines the default filter factor for each predicate in the selection clause.
• Extracts attributes of the table from internally stored information.
• Performs an estimate key range to determine the true filter factor of the predicates when the selection predicates match the left-most keys of an index.
• Determines the cost of creating an index over a table if an index is required.
• Determines the cost of using a sort routine if selection conditions apply and an index is required.
• Determines the cost of dataspace scan processing if an index is not required.
• For each index available, in the order of most recently created to oldest, Optimizer does the following until its time limit is exceeded:
  • Extracts attributes of the index from internally stored statistics.
  • Determines if the index meets the selection criteria.
  • Determines the cost of using the index using the estimated page faults and the predicate filter factors to help determine the cost.
  • Compares the cost of using this index with the previous cost (current best).
  • Selects the cheapest one.
  • Continues to search for best index until time out or no more indexes.

The time limit factor controls how much time is spent choosing an implementation. It is based on how much time has been spent and the current best implementation cost found. Dynamic SQL queries are subject to Optimizer time restrictions. Static SQL queries 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, Optimizer considers five or six indexes (for each table of a join) before running out of optimization time.