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

Planner should use path-level multikey info to generate covered plans when possible

    • Type: Icon: Improvement Improvement
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.5.2
    • Affects Version/s: None
    • Component/s: Index Maintenance
    • Labels:
      None
    • Fully Compatible
    • Query 2017-01-23

      In this example, I want to get a list of user names for a particular event.

      > db.col2.insert({name: "ag", event: ["open", "tourney"]})
      > db.col2.insert({name: "joe", event: ["match", "event"]})
      > db.col2.insert({name: "bill", event: ["open", "event"]})
      > db.col2.ensureIndex({event: 1, name: 1})
      > db.col2.find({event: "open"}, {name: 1, _id: 0})
      { "name" : "ag" }
      { "name" : "bill" }
      > db.col2.find({event: "open"}, {name: 1, _id: 0}).explain()
      {
      	"cursor" : "BtreeCursor event_1_name_1",
      	"nscanned" : 2,
      	"nscannedObjects" : 2,
      	"n" : 2,
      	"millis" : 0,
      	"nYields" : 0,
      	"nChunkSkips" : 0,
      	"isMultiKey" : true,
      	"indexOnly" : false,
      	"indexBounds" : {
      		"event" : [
      			[
      				"open",
      				"open"
      			]
      		],
      		"name" : [
      			[
      				{
      					"$minElement" : 1
      				},
      				{
      					"$maxElement" : 1
      				}
      			]
      		]
      	}
      }
      

      See that multikey is true even though the requested field (name) is not multikey.
      Since we already track duplicate doc location, it should be easy to use covered index to return just name info.
      That could speed up a lot certain queries.
      We could move multiKey flag at the field level, and decide based on what is returned.

      An alternative would be to add a hint flag to force covered index.
      In this case output would be same.
      In case of a true multikey, the array could be incomplete or with wrong order, but that would be expected.

            Assignee:
            david.storch@mongodb.com David Storch
            Reporter:
            antoine Antoine Girbal
            Votes:
            32 Vote for this issue
            Watchers:
            29 Start watching this issue

              Created:
              Updated:
              Resolved: