Reading slotBasedPlan explain output for time series
Parent: MongoDB Time-Series Query and Index Optimization · Published reference · snapshot 2026-10-22 · skill ranked-3558d9b3
↓ Facts as markdownall context files
Source-anchored research for Reading slotBasedPlan explain output for time series. 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
- Do not equate `COLLSCAN` with scanning every logical measurement. In a dated MongoDB 5.0 example, Percona reports a time-series `COLLSCAN` with 8 documents examined because the scan reads backing buckets; the regular-collection comparison examined 299,997 documents. Compare `totalDocsExamined` and bucket filters or index bounds before calling it a full measurement scan. (medium confidence) (verified as of 2021-10-20) [source]
- One 2025 time-series explain example shows the aggregation's `$cursor.queryPlanner` targeting `system.buckets.events`, with generated `control.min.ts` and `control.max.ts` predicates and an `IXSCAN` key pattern on both control fields. When a time-field index appears unused, inspect the actual namespace, `parsedQuery`, and index bounds before judging the plan from the user-facing field name. (medium confidence) [source]
- `explain.queryPlanner.winningPlan.slotBasedPlan` appears when the selected query used the slot-based execution engine (SBE). Its `stages` value is a string describing execution order, operations, and slot assignments. MongoDB marks this output for internal use, so its exact details can change by release. (high confidence) [source]
How-to and procedures
- Use `executionStats` to assess completed work: `executionStages` describes the winning plan's execution, and `nReturned`, `totalDocsExamined`, and `totalKeysExamined` report result and scan counts. `executionTimeMillis` includes plan selection and trial-phase time, excludes network transfer, and is not necessarily representative of steady-state query time. (high confidence) [source]
Problems, failure modes and limitations
- Index access and query-engine choice are separate diagnostics. A November 20, 2025 community slow-query log for a time-series operation showed an IXSCAN plan summary and queryFramework value classic; check the index plan and SBE or block-processing markers separately. (medium confidence) (verified as of 2025-11-20) [source]
Comparisons and alternatives
- `executionStats.executionTimeMillis` includes plan selection and query execution but excludes network time. MongoDB warns that it may not represent steady-state query time because explain bypasses the plan cache; compare it with representative application executions instead of treating it as request latency. (high confidence) [source]
Facts and statements
- Starting in MongoDB 8.0, a time-series query that uses block processing shows `ts_bucket_to_cellblock` and `block_to_row` in `slotBasedPlan.stages`. `ts_bucket_to_cellblock` converts selected bucket fields into CellBlocks; `block_to_row` converts block values into row slots for later SBE stages. (high confidence) (verified as of 2025-07-21) [source]
- Read `ts_bucket_to_cellblock` and `block_to_row` together. MongoDB's server README describes the first stage converting a bucket into column cell blocks and `BlockToRowStage` turning block values into row slots; it also says `BlockToRowStage` is not specific to time series. This means `block_to_row` alone is not a time-series block-processing signal. (medium confidence) (verified as of 2026-10-22) [source]
- Locate the correct explain branch before interpreting it: classic plans use `winningPlan.stage` and nested `inputStage`, while SBE plans expose `winningPlan.queryPlan` and `slotBasedPlan`. Aggregation explain output has a top-level `stages` array, normally with the data-access plan under its first `$cursor` entry, so a missing top-level `queryPlanner` or `slotBasedPlan` does not by itself mean the plan is absent. (high confidence) [source]
- MongoDB may automatically use block processing only for eligible time-series workloads. Its manual describes long-running aggregation pipelines beginning with `$match`, optionally `$sort` on the `timeField`, and `$group`; it also says performance gains vary by workload and instance configuration. The stage markers show the execution strategy used by that explain, not a guaranteed speedup. (high confidence) (verified as of 2026-10-22) [source]
- The presence of `slotBasedPlan` alone does not prove that a time-series query used block processing or improved performance. MongoDB applies block processing automatically only to eligible queries, and its manual says results vary with workload and database configuration; check for the two block markers and evaluate execution statistics for the workload. (high confidence) [source]
- A Stack Overflow time-series case reported COLLSCAN for numeric epoch-millisecond range predicates and IXSCAN for BSON Date predicates. An answer recommended checking parsedQuery to verify that the client sent a BSON Date. (low confidence) [source]
Children
- No children recorded.