# $top/$bottom accumulators rewrite > Source-anchored research for $top/$bottom accumulators rewrite. Run status: COMPLETED. Parent: [MongoDB Advanced Explain: Aggregation, Sharded Plans, Loose Index Scans and the 8.3 Cost-Based Ranker](https://llms-explorer.com/tree/mongodb-advanced-explain-aggregation-sharded-plans-loose-index-scans-and-the-8-3-cost-based-ranker/) · 3 facets · 6 facts · page: https://llms-explorer.com/tree/top-bottom-accumulators-rewrite/ ## 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](https://jira.mongodb.org/browse/SERVER-9507) ## 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](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/timeseries/README.md) - 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](https://jira.mongodb.org/browse/SERVER-110803) ## 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](https://github.com/mongodb/mongo/blob/master/src/mongo/db/query/timeseries/README.md) - 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](https://github.com/mongodb/mongo/blob/master/src/mongo/db/pipeline/document_source_group.h) - 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](https://webcodingcenter.com/mongodb/the-aggregation-pipeline--grouping-and-accumulator-expressions.html)