# Planner plan scoring and EOF bonus > Source-anchored research for Planner plan scoring and EOF bonus. Run status: COMPLETED. Parent: [MongoDB Compound Index Design: ESR, Selectivity, Covering and Multikey Bounds](https://llms-explorer.com/tree/mongodb-compound-index-design-esr-selectivity-covering-and-multikey-bounds/) · 4 facets · 10 facts · page: https://llms-explorer.com/tree/planner-plan-scoring-and-eof-bonus/ ## 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](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/plan_ranker_util.h) - 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](https://jira.mongodb.org/browse/SERVER-20616) - 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](https://www.mongodb.com/docs/manual/core/query-plans/) - 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](https://arxiv.org/html/2409.16544) ## 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](https://github.com/mongodb/mongo/blob/35647d07bc4bc11966c90fe7100eb1db0b0ac1d9/src/mongo/db/exec/runtime_planners/classic_runtime_planner/README.md) ## 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](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/plan_ranker.cpp) - 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](https://dev.to/franckpachot/mongodb-index-intersection-and-postgresql-bitmap-scan-40a6) ## 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](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/query/plan_ranker.h) - 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](https://github.com/mongodb/mongo/blob/35647d07bc4bc11966c90fe7100eb1db0b0ac1d9/src/mongo/db/exec/runtime_planners/classic_runtime_planner/README.md) - 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](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/plan_ranker.h)