[SERVER-15225] CachedPlanStage should execute for trial period and re-plan if query performs poorly Created: 11/Sep/14 Updated: 30/Aug/22 Resolved: 14/Apr/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 3.0.4, 3.1.2 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | David Storch |
| Resolution: | Done | Votes: | 2 |
| Labels: | 2426 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Completed: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Quint Iteration 3.1.2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Issue Status as of Jun 19, 2015 ISSUE SUMMARY This improvement 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 improvement is not enabled by default. To enable by default set the internalQueryCacheReplanningEnabled parameter to true 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 enable using setParameter:
This improvement can be disabled as follows:
USER IMPACT WORKAROUNDS
AFFECTED VERSIONS FIX VERSION Original descriptionAs of 2.6.0, query plans that are executed from the plan cache are considered for cache eviction only after the plan finishes execution. Instead, it should be possible to evict plans from the cache before they finish executing, in the case where the performance of the plan is much worse than when it was first cached. In order to do this, we will need to investigate alternative plan cache eviction policies. This is because the current eviction policy accesses statistics from the last 20 executions of the cached plan (which won't be available) in order to make an eviction decision. The current eviction policy also does not perform well, in practice. |
| Comments |
| Comment by Githook User [ 03/Jun/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: This is a minimal backport of the rewrite to the CachedPlanStage. The functionality is behind |
| Comment by Githook User [ 17/Apr/15 ] |
|
Author: {u'username': u'jrassi', u'name': u'Jason Rassi', u'email': u'rassi@10gen.com'}Message: |
| Comment by Githook User [ 14/Apr/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |