$top/$bottom accumulators rewrite
Parent: MongoDB Advanced Explain: Aggregation, Sharded Plans, Loose Index Scans and the 8.3 Cost-Based Ranker · Published reference · snapshot 2026-10-22 · skill ranked-5214f257
↓ Facts as markdownall context files
Source-anchored research for $top/$bottom accumulators rewrite. 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
- The older SERVER-9507 optimization uses a matching index to skip many entries for `$sort` + `$group` + `$first`; the current group header documents `$topN`/`$bottomN` with `n: 1` as a separate desugaring that may enable `DISTINCT_SCAN` when a suitable index exists. Treat the accumulator rewrite and index-scan selection as related but distinct optimizations. (medium confidence) (verified as of 2026-10-22) [source]
Problems, failure modes and limitations
- The documented time-series conditions are: `$sort` has no limit; the sort is not on the meta field, which uses a different reorder; no group accumulator depends on the sorted input (`$firstN` and `$lastN` are explicitly unsupported); and `$_internalUnpackBucket` directly precedes `$sort` and `$group`. Compound sort keys and compound group keys are supported. (high confidence) (verified as of 2026-10-22) [source]
- SERVER-110803 reports a wrong-result case where a preceding `$sort` enables `DISTINCT_SCAN` and `$top`/`$bottom` ignore their own `sortBy`. The ticket says queries before MongoDB 8.0.20 or 8.2.4 may be affected; its 8.2.x caveat requires `featureFlagShardFilteringDistinctScan` to be false. (low confidence) (verified as of 2026-10-22) [source]
Facts and statements
- In the documented time-series path, MongoDB 8.0+ rewrites an eligible unbounded `$sort` followed by `$group` with `$first`/`$last`: it removes the pipeline-level `$sort` and replaces those accumulators with `$top`/`$bottom` using the same sort keys. The stated purpose is to avoid the blocking top-level sort. (high confidence) (verified as of 2026-10-22) [source]
- The current `DocumentSourceGroup::tryToAbsorbTopKSort()` comment says this rewrite is invoked only from time-series and names SERVER-28980 as TODO work to lift the restriction. The time-series README also requires `$_internalUnpackBucket` immediately before `$sort` and `$group`, so ordinary collection pipelines should not be assumed to receive this rewrite. (high confidence) (verified as of 2026-10-22) [source]
- Two independent operator guides describe the rationale: `$sort` is blocking and must consume all input, while `$top` carries its own `sortBy` and keeps one candidate per group. This explains the logical opportunity to remove a full-stream sort, but it does not establish a workload-specific speedup or physical plan. (medium confidence) [source]
Children
- No children recorded.