Why is a covered query sometimes slower in MongoDB? - mongodb

Question

I was under the impression that covered queries were always faster than scanning the collection itself. So why is this covered query slower?
Covered query:
> db.group_panel_responses.find({}, {_id: 0, _panel_id: 1, _group_id: 1, response_count: 1}).hint({_panel_id: 1, _group_id: 1, response_count: -1}).explain()
{
"cursor" : "BtreeCursor _panel_id_1__group_id_1_response_count_-1",
"isMultiKey" : false,
"n" : 20000,
"nscannedObjects" : 0,
"nscanned" : 20000,
"nscannedObjectsAllPlans" : 0,
"nscannedAllPlans" : 20000,
"scanAndOrder" : false,
"indexOnly" : true,
"nYields" : 156,
"nChunkSkips" : 0,
"millis" : 44,
"indexBounds" : {
"_panel_id" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
],
"_group_id" : [
[
{
"$minElement" : 1
},
{
"$maxElement" : 1
}
]
],
"response_count" : [
[
{
"$maxElement" : 1
},
{
"$minElement" : 1
}
]
]
},
"server" : "DAAVID.local:27017",
"filterSet" : false
}
Same query but without hinting at the index, so not a covered query:
> db.group_panel_responses.find({}, {_id: 0, _panel_id: 1, _group_id: 1, response_count: 1}).explain()
{
"cursor" : "BasicCursor",
"isMultiKey" : false,
"n" : 20000,
"nscannedObjects" : 20000,
"nscanned" : 20000,
"nscannedObjectsAllPlans" : 20000,
"nscannedAllPlans" : 20000,
"scanAndOrder" : false,
"indexOnly" : false,
"nYields" : 156,
"nChunkSkips" : 0,
"millis" : 40,
"server" : "DAAVID.local:27017",
"filterSet" : false
}

Answer 1

Keep in mind that a query that is covered by an index is generally faster than a regular query because you can retrieve the fields for each document in one step, as opposed to two in a regular query, where you hit the index to find the location of the document and then hit the collection itself to retrieve the fields.
To over simplify a bit, in a normal case where my selection criteria would retrieve 20000 documents, a normal query would have 40000 accesses (20000 for the index and 20000 for the collection) while a covered query would only have 20000 accesses.
In your test case, however, you have no selection criteria. So both queries, covered and uncovered, will do a full collection scan. In this case you lose almost all of the performance boost of a covered query with selection criteria.
If you really want to test the value of a covered query I'd use a much larger document collection and a much more selective query. If the test you are using is representative of your actual production usage I would not expect any performance boost at all.