WL#5869: Optimizer cost: use Cost_estimate in range optimizer
Status: Complete
Cost is currently represented in two ways in different parts of the MySQL Range Optimizer: * double cost : the sum of disk lookup cost, CPU comparison costs etc. * Cost_estimate: cost represented in "cost estimate" object in which CPU, memory, and disk costs are kept separate. This WL is for moving from the first representation to the Cost_estimate representation in the MySQL Range Optimizer User Documentation ================== No functional changes. No user documentation required.
This worklog should not introduce any functional changes. It is mostly about replacing cost representation internally in the range optimizer: from double to Cost_estimate objects. Functional requirements: F-1: No existing functionality shall be changed F-2: Due to use of floating point arithmetic minor rounding errors may cause changes to query plans in the case where alternative query plans have almost identical cost estimates. Non-functional requirements: NF-1: Changing to use a new cost representation may increase CPU usage and influence the time it takes for optimizing a query. If there is an increase in CPU usage, this should be small, less than one percent.
The code that will be changed is in opt_range.{cc,h}. All costs of type double will be replaced with Cost_estimate. The current "double" representation does not differentiate between different types of cost, but from the context it is self explanatory what kind of cost is meant in the code. Thus, cost related to... * CPU cycles will go into Cost_estimate::cpu_cost * I/O operations will go into Cost_estimate::io_cost * memory will go into Cost_estimate::mem_cost The total cost should not change because of this. To ensure that this is the case, DBUG_ASSERT() will compare the old cost representation with the new Cost_estimate representation all over the range optimizer. All mtr tests and RQG testing relevant for range optimization needs to pass before the old cost representation can be removed.
Copyright (c) 2000, 2024, Oracle Corporation and/or its affiliates. All rights reserved.