|
Looks like this is fixed in 3.2:
> db.tailable.find().addOption(DBQuery.Option.tailable)._addSpecial("$maxScan", 100).explain("executionStats");
|
{
|
"queryPlanner" : {
|
"plannerVersion" : 1,
|
"namespace" : "test.tailable",
|
"indexFilterSet" : false,
|
"parsedQuery" : {
|
"$and" : [ ]
|
},
|
"winningPlan" : {
|
"stage" : "COLLSCAN",
|
"filter" : {
|
"$and" : [ ]
|
},
|
"direction" : "forward"
|
},
|
"rejectedPlans" : [ ]
|
},
|
"executionStats" : {
|
"executionSuccess" : true,
|
"nReturned" : 100,
|
"executionTimeMillis" : 0,
|
"totalKeysExamined" : 0,
|
"totalDocsExamined" : 100,
|
"executionStages" : {
|
"stage" : "COLLSCAN",
|
"filter" : {
|
"$and" : [ ]
|
},
|
"nReturned" : 100,
|
"executionTimeMillisEstimate" : 0,
|
"works" : 102,
|
"advanced" : 100,
|
"needTime" : 1,
|
"needYield" : 0,
|
"saveState" : 0,
|
"restoreState" : 0,
|
"isEOF" : 1,
|
"invalidates" : 0,
|
"direction" : "forward",
|
"docsExamined" : 100
|
}
|
},
|
"serverInfo" : {
|
"host" : "dstorch",
|
"port" : 27017,
|
"version" : "3.2.0-rc3-156-g26197aa",
|
"gitVersion" : "26197aa127cbd44ba5f27a1ae8326774d4de1a76"
|
},
|
"ok" : 1
|
}
|
I'm guessing this was fixed as part of SERVER-16444, which involved a significant rewrite of the CollectionScan query execution stage.
|