ISSUE SUMMARY
The query optimizer caches plans for each query shape and reuses these plans for a time. In situations where the performance of the cached plan is poor for a particular instance of the query shape, the optimizer may select a plan with poor performance and fail to evict the cache entry. This behavior may impact deployments where two queries with the same shape have different performance characteristics (generally due to a difference in selectivity).
SERVER-15225 makes the query planner evaluate the cost of the cached query plan, and if the cost of this plan is too high, the query planner switches to a more efficient plan. This more efficient plan is then cached for future use.
This ticket enables the optimization from SERVER-15225 by default.
To disable this behavior users can set internalQueryCacheReplanningEnabled parameter to false using the setParameter command on a running system, or at start time using the setParameter commandline option or setParameter in the configuration file.
For example, to disable using setParameter:
db.runCommand({setParameter: 1, internalQueryCacheReplanningEnabled: false})
This improvement can be re-enabled as follows:
db.runCommand({setParameter: 1, internalQueryCacheReplanningEnabled: true})
See SERVER-15225 for additional details.
Original description
SERVER-15225 introduced aggressive plan cache eviction and replanning which can solve a large class of query plan selection problems. This change was backported to the 3.0 branch, first available in 3.0.4, but is disabled by default. We should flip the default so that the plan cache eviction and replanning is available by default.
- is related to
-
SERVER-15225 CachedPlanStage should execute for trial period and re-plan if query performs poorly
- Closed