currentOp planSummary for running operations
Parent: MongoDB Explain Plans, Query Planner and Plan Cache · Published reference · snapshot 2026-10-20 · skill ranked-e3681427
↓ Facts as markdownall context files
Source-anchored research for currentOp planSummary for running operations. 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.
Definitions
- planSummary is a compact scan-type signal: COLLSCAN indicates a collection scan, while IXSCAN { ... } indicates an index scan and includes the index specification. It does not provide the full winning-plan tree or per-execution work counters. (high confidence) [source]
How it works
- Treat planSummary as a triage signal. When a live operation needs deeper investigation, MongoDB recommends explain() to inspect its query plan and execution statistics; Datadog likewise distinguishes currentOp operation samples from explain plans, and Netcracker's troubleshooting guide contrasts planSummary with explain('executionStats') and profiler counters. (high confidence) [source]
How-to and procedures
- Use $currentOp from the admin database to inspect a live stream of operation and session records. Operation records can include active, secs_running, and planSummary, which lets an operator pair elapsed time with the query access path when those fields are present. (high confidence) [source]
Problems, failure modes and limitations
- Treat a scan summary as triage, not proof of query efficiency. Netdata notes that an IXSCAN can still be slow when index selectivity is poor, and Netcracker's example shows an IXSCAN beneath FETCH examining 97,436 documents to return one result. Use explain('executionStats') or profiler metrics to inspect examined and returned counts. (high confidence) [source]
- $currentOp describes operations present in its current result stream, not a history of completed queries. MongoDB directs operators to the database profiler to find slow queries over a specified period; Percona contrasts real-time currentOp inspection with retrospective log review. (high confidence) [source]
- For live diagnosis, MongoDB's $currentOp stage returns information about operations currently running. MongoDB's slow-query procedure filters those results by secs_running and checks active and waitingForLock alongside planSummary; Percona and Datadog also describe currentOp as a source for in-progress operation monitoring. (high confidence) [source]
- The $currentOp documentation says the top-level planSummary is unavailable when an aggregation runs on mongos with localOps: true; cursor.planSummary is also unavailable in that scope and when reporting idleCursors. By implication, a missing field in those contexts cannot be counted as evidence of COLLSCAN. (low confidence) [source]
Comparisons and alternatives
- MongoDB recommends the $currentOp aggregation stage instead of the currentOp command and db.currentOp() helper. The command is deprecated starting in MongoDB 6.2. (high confidence) (verified as of 2026-10-20) [source]
Facts and statements
- For getMore records, $currentOp documents cursor metadata under cursor, including cursor.planSummary with availability limits. MongoDB tracked an older bug that duplicated planSummary at both the active operation and cursor levels; the issue lists the fix in version 4.1.7. (high confidence) [source]
- A MongoDB community thread reports that one operator's planSummary:null rows were insert commands after they checked the operation type. This example and the manual's cursor-focused scan definitions show why null alone should not be interpreted as COLLSCAN. (medium confidence) [source]
- The current manual deprecates the legacy currentOp database command starting in MongoDB 6.2 and recommends the $currentOp aggregation stage. The db.currentOp() mongosh helper uses the aggregation stage starting in MongoDB 5.0. (high confidence) (verified as of 2026-10-20) [source]
- MongoDB's historical SERVER-23259 issue says planSummary became visible in db.currentOp() after plan selection completed and describes that implementation as available only for legacy OP_QUERY reads. The ticket does not establish equivalent timing for modern command-style reads. (low confidence) [source]
Children
- No children recorded.