[SERVER-13744] Tailable cursors do not honor $maxScan values Created: 25/Apr/14  Updated: 04/Dec/15  Resolved: 04/Dec/15

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.6.0, 2.6.1-rc0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kamran K. Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Operating System: ALL
Steps To Reproduce:

db.createCollection("tailable", {size: 1000000, capped: true});
 
for (var i = 0; i < 10000; i++) {
    db.tailable.insert({i: i});
}
 
db.tailable.find().addOption(DBQuery.Option.tailable)._addSpecial("$maxScan", 100).explain();

Participants:

 Description   

In 2.4.10, tailable cursors seem to honor $maxScan values:

> db.tailable.find().addOption(DBQuery.Option.tailable)._addSpecial("$maxScan", 100).explain();
{
	"cursor" : "ForwardCappedCursor",
	"isMultiKey" : false,
	"n" : 100,
	"nscannedObjects" : 100,
	"nscanned" : 101,
	"nscannedObjectsAllPlans" : 100,
	"nscannedAllPlans" : 101,
...

In 2.6 and 2.6.1-rc0, they do not:

> db.tailable.find().addOption(DBQuery.Option.tailable)._addSpecial("$maxScan", 100).explain();
{
	"cursor" : "BasicCursor",
	"isMultiKey" : false,
	"n" : 10000,
	"nscannedObjects" : 10000,
	"nscanned" : 10000,
	"nscannedObjectsAllPlans" : 10000,
	"nscannedAllPlans" : 10000,
...



 Comments   
Comment by David Storch [ 04/Dec/15 ]

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.

Generated at Thu Feb 08 03:32:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.