Multi-planner trial period and candidate plan ranking
Parent: Replanning loops and replanReason · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Multi-planner trial period and candidate plan ranking. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Structure and components
- The 2024 University of Sydney study describes a default 101-result trial target and max(10000, 0.3 times collection document count) work budget for its MongoDB 7.0.1 analysis. These are historical, configuration-dependent values, not universal wall-clock time limits. (low confidence) [source]
How it works
- In the r8.0.0 classic implementation, pickBestPlan repeatedly calls workAllPlans; each viable candidate receives a work() call per round. The trial ends when its work budget is exhausted, a candidate reaches the result target, or a candidate reaches EOF. This is interleaved execution, not evidence of one concurrent thread per candidate. (medium confidence) [source]
- A trial samples the beginning of each candidate's execution. Correlated data can make early productivity unrepresentative and cause a suboptimal choice; the FPTP experiments also show that productivity can diverge from full execution cost. (medium confidence) [source]
Problems, failure modes and limitations
- For diagnostics, explain("allPlansExecution") exposes partial execution statistics collected during plan selection for winning and rejected candidates. Explain ignores existing cached plans and does not cache its winner, so it cannot directly replay the cached-plan path that produced a production replanReason. (medium confidence) [source]
- SERVER-62150 documents historical SBE trials that ran each candidate to its trial limit and could spend excessive planning time when a poor plan ran first. The issue states that MongoDB 8.0 fixed this by using classic multiplanning even when the selected plan executes in SBE; execution engine alone therefore does not identify trial scheduling. (low confidence) (verified as of 2025-07-01) [source]
- Tao et al.'s experiments on MongoDB 7.0.1 found that productivity undercounted the combined index-entry and document-fetch cost. Their simple range-query workloads and memory-resident indexes limit generalization to other versions and workloads. (low confidence) [source]
Comparisons and alternatives
- Percona reports a classic-engine incident with fromMultiPlanner:true, replanned:true and an expected-2-versus-at-least-20-works replanReason. Its planningTimeMicros was 215107053 versus durationMillis 215107, showing that repeated selection can consume nearly the entire operation; this is one example, not a universal cost. (low confidence) [source]
- explain ignores existing plan-cache entries and prevents caching its chosen plan. Use it to inspect fresh candidate selection, rather than treating it as a direct observation of cached execution. (medium confidence) [source]
Facts and statements
- The classic multi-planner compares candidate plans by executing a bounded trial and ranking observed productivity. It does not fully execute every alternative or guarantee the lowest full-query runtime. (medium confidence) [source]
- MongoDB r8.0.0 PlanScorer starts with 1 plus productivity and adds small bonuses for avoiding FETCH, blocking SORT, and index intersection. Higher scores rank better; scores are not milliseconds. This describes the base scorer, not every later ranking adjustment. (medium confidence) [source]
- A favorable trial score need not predict the fastest complete query: the Sydney researchers found index-scan preference in MongoDB 7.0.1 two-range find workloads even where a collection scan was faster. This is a workload- and version-scoped experimental finding. (low confidence) [source]
- The current manual scopes pure trial-ranking explanations: starting with 8.3, eligible queries use multi-planning with cost-based-ranker backup. After an unsuccessful short trial, rules determine whether multi-planning continues or CBR evaluates estimated plan-node costs. It is inaccurate to say CBR entirely replaces the trial. (medium confidence) (verified as of 2026-10-30) [source]
- Classic ranking combines a base score of 1, productivity measured as results divided by work, small bonuses for avoiding fetch, blocking sort and index intersection, and a completion bonus described in the FPTP study. (medium confidence) [source]
- In r8.0.0 PlanScorer::calculateScore, epsilon is min(1 / (10 * max(advances, 1)), 1e-4); it uses advances, not work units. Scores primarily impose an ordering and are not elapsed-time predictions. (low confidence) [source]
- explain('allPlansExecution') includes partial selection-phase statistics for winning and rejected plans. These are bounded-trial observations, not complete executions of every rejected candidate. (medium confidence) [source]
Children
- Classic plan productivity and completion bonuses (frontier)
- Trial sampling bias from correlated data (frontier)
- Interpreting partial allPlansExecution statistics (frontier)
Frontier under this node: Classic plan productivity and completion bonuses, Interpreting partial allPlansExecution statistics, Trial sampling bias from correlated data