-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Querying
-
Query Optimization
-
Fully Compatible
-
ALL
-
(copied to CRM)
On standalones, the explain command does not support readConcern, as it uses the default implementation of supportsReadConcern() (see here). For example
db.c.runCommand({explain: {find: "c", query: {a: 1}}, readConcern: {level: "available"}}) // Error
It is, however, legal to provide a readConcern in the inner command. For example:
db.c.runCommand({explain: {count: "c", query: {a: 1}, readConcern: {level: "available"}}})
When running explain on a sharded cluster, mongos will "hoist" generic options from the inner command into the top-level "explain" command which it sends to the shards. See here). The result of this is that attempting to explain a query with a readConcern other than "local" on mongos throws an error.
It is possible to get different query plans using different readConcern levels, and it would be extremely useful if explain() could reflect this. For example, queries run with readConcern "available" do not perform orphan filtering, and do not need a SHARD_FILTER stage. In many cases, this can lead to a completely different plan being used than if the query had been run with a stronger readConcern.
- related to
-
SERVER-28678 The explain command should reject explained commands containing readConcern or writeConcern
- Closed