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

Explain command on sharded clusters does not support readConcern

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: In Code Review
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Querying
    • Labels:
    • Operating System:
      ALL
    • Case:

      Description

      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.

        Attachments

          Activity

            People

            Assignee:
            jacob.evans Jacob Evans
            Reporter:
            ian.boros Ian Boros
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Dates

              Created:
              Updated: