# explain() executionStats reading > Source-anchored research for explain() executionStats reading. 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/) · 3 facets · 7 facts · page: https://llms-explorer.com/tree/explain-executionstats-reading/ ## How-to and procedures - Use nReturned, totalKeysExamined, and totalDocsExamined together: nReturned counts documents returned by the winning plan, totalKeysExamined counts scanned index entries, and totalDocsExamined counts document examinations, including filtered-out and repeated examinations. A gap is a clue to inspect the stage tree and filters, not a universal efficiency verdict, because stage counts can describe intermediate work and a document can be counted more than once. (high confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/manual/reference/explain-results.md) ## Comparisons and alternatives - MongoDB defines executionTimeMillis as the time spent on plan selection plus query execution, including the plan trial phase but excluding network transmission. MongoDB warns that explain timing may differ from steady-state query latency because explain bypasses the plan cache and does not cache its selected plan. Use it with work counters, and measure representative normal traffic when latency is the target. (high confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/manual/reference/explain-results.md) ## Facts and statements - For mongosh cursor.explain(), queryPlanner is the default. The executionStats verbosity chooses the winning plan, runs it to completion, and reports its execution statistics; it does not report completed run statistics for rejected plans. allPlansExecution adds partial candidate-plan statistics captured during plan selection. (high confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/manual/reference/method/cursor.explain.md) - Read `executionStats` by comparing top-level `nReturned`, `totalKeysExamined`, and `totalDocsExamined`, then inspect `executionStages` from its leaf stages toward the root. Stage names and child fields show where the plan scans (`COLLSCAN` or `IXSCAN`), fetches documents (`FETCH`), and performs other work. The plan tree can be nested differently across classic and slot-based execution engines and can change between MongoDB versions. (high confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/v8.0/reference/explain-results/) - Do not add `executionTimeMillisEstimate` values across stages to reconstruct total query duration. MongoDB documents these stage timings as estimates, and its explain implementation adds the overall elapsed-time value at the top level without changing individual stage timings. (high confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/v8.0/reference/explain-results/) - A Percona example published 2023-07-26 shows a regex query returning 19,851 documents before and after adding a name index: totalDocsExamined fell from 10,000,000 to 19,851, while totalKeysExamined rose from 0 to 10,000,000 and executionTimeMillis changed from 4,171 to 4,283. This historical case shows why an IXSCAN or a lower document-examination count alone does not prove lower elapsed time. (high confidence) (verified as of 2023-07-26) — [source](https://www.percona.com/blog/ten-recommendations-for-running-your-mongodb-environment/) - MongoDB documents that explain output can vary between the classic and slot-based execution engines and that documented fields may change. Amazon DocumentDB separately defines docsExamined as stage-local and totalDocsExamined as a total across its execution stages. Treat those DocumentDB details as product-specific and verify field scope against the server and version being measured. (high confidence) (verified as of 2026-10-21) — [source](https://www.mongodb.com/docs/manual/reference/explain-results.md)