Planner plan scoring and EOF bonus
Parent: MongoDB Compound Index Design: ESR, Selectivity, Covering and Multikey Bounds · Published reference · snapshot 2026-10-20 · skill ranked-902d7508
↓ Facts as markdownall context files
Source-anchored research for Planner plan scoring and EOF bonus. 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.
How it works
- In current MongoDB plan_ranker_util.h, pickBestPlan() sets eofBonus to 1 and adds that point when the candidate root statistics report common.isEOF. The code comment says multiple candidates that hit EOF during the same round-robin calls also receive the bonus. (high confidence) (verified as of 2026-10-20) [source]
- A trial sample can mis-rank plans when index order and predicate values are correlated: MongoDB issue SERVER-20616 describes a range scan that looks productive on the early sample, and a University of Sydney study found MongoDB 7.0.1 could prefer index scans over faster collection scans, with more than twice the optimal runtime in some tested cases. (medium confidence) [source]
- The EOF formula describes the classic multi-planner path, not every eligible query choice: the current manual says multi-planning with a cost-based ranker backup is the default plan-selection mechanism for eligible queries starting in MongoDB 8.3, and the backup may evaluate plans when the initial trial is unsuccessful. (high confidence) (verified as of 2026-10-20) [source]
- A University of Sydney study evaluated FPTP on MongoDB 7.0.1 using simple two-range query families. It found cases where the optimizer chose index scans even though collection scans ran faster, and argued that advanced-per-work scoring can undercount index access plus document-fetch cost. The study does not isolate EOF bonus as the cause of every misranking. (medium confidence) [source]
Problems, failure modes and limitations
- EOF is a distinct classic trial stop condition from reaching the result-batch limit or maximum work limit; it means the candidate returned all of its results during the trial. (high confidence) (verified as of 2026-10-20) [source]
Comparisons and alternatives
- The productivity score is not elapsed time: an idealo report on MongoDB 4.0 describes a candidate with a slower estimated execution time (23 ms versus 6 ms) winning because it produced more advanced results during the trial. (medium confidence) [source]
- A Nov 2025 example by Franck Pachot reports candidate scores of 2.012, 1.010, and 1.007; the first candidate’s one-point lead mostly comes from reaching EOF during the trial. This illustrates how trial completion can dominate small productivity differences, but it is one query example rather than a general performance result. (medium confidence) [source]
Facts and statements
- In the current classic ranker, a candidate's basic score starts at 1 and adds root productivity (advanced divided by works) plus small tie-breaker bonuses that favor avoiding fetch, blocking sort, and index-intersection stages; some query shapes have additional score adjustments. (high confidence) (verified as of 2026-10-20) [source]
- MongoDB’s classic runtime-planner README documents the candidate score as 1 + (advanced / works) + eofBonus + tieBreakers; the candidate with the highest score wins. This formula describes that classic runtime-planner path. (high confidence) [source]
- MongoDB’s current PlanScorer base class leaves the productivity calculation to concrete scorer implementations. The classic README’s advanced / works formula should not be assumed to describe every execution engine or ranking path. (medium confidence) (verified as of 2026-10-20) [source]
Children
- No children recorded.