# Reading slotBasedPlan explain output for time series > Source-anchored research for Reading slotBasedPlan explain output for time series. Run status: COMPLETED. Parent: [MongoDB Time-Series Query and Index Optimization](https://llms-explorer.com/tree/mongodb-time-series-query-and-index-optimization/) · 5 facets · 12 facts · page: https://llms-explorer.com/tree/reading-slotbasedplan-explain-output-for-time-series/ ## 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](https://www.percona.com/blog/mongodb-5-0-time-series-collections/) - 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](https://stackoverflow.com/questions/79524211/mongodb-timeseries-query-not-using-index-and-taking-excessively-long) - `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](https://www.mongodb.com/docs/v8.0/reference/explain-results/) ## 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](https://www.mongodb.com/docs/v8.0/reference/explain-results/) ## 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](https://www.reddit.com/r/mongodb/comments/1p5o4cz/improving_time_series_performance/) ## 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](https://www.mongodb.com/docs/v8.0/reference/explain-results/) ## 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](https://www.mongodb.com/docs/v8.0/reference/explain-results/) - 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](https://www.mongodb.com/docs/v8.0/reference/explain-results/) - 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](https://www.mongodb.com/docs/v8.0/reference/explain-results/) - 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](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-querying/) - 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](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-querying/) - 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](https://stackoverflow.com/questions/79524211/mongodb-timeseries-query-not-using-index-and-taking-excessively-long)