Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-51795

Explain command on sharded clusters does not support readConcern

    • Query Optimization
    • Fully Compatible
    • ALL

      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.

            Assignee:
            henri.nikku@mongodb.com Henri Nikku
            Reporter:
            ian.boros@mongodb.com Ian Boros
            Votes:
            0 Vote for this issue
            Watchers:
            18 Start watching this issue

              Created:
              Updated:
              Resolved: