[SERVER-13337] Re-enable fast path for _id equality queries with projection Created: 24/Mar/14  Updated: 11/Mar/15  Resolved: 01/May/14

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

Type: Task Priority: Major - P3
Reporter: Daniel Pasette (Inactive) Assignee: David Storch
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-13663 Perf regression for workload that upd... Closed
Related
related to SERVER-13685 refactor fast-path for _id queries to... Closed
related to SERVER-13842 Optimize non-simple projections Backlog
is related to SERVER-14302 Equality queries on _id with projecti... Closed
Tested
Backwards Compatibility: Fully Compatible
Backport Completed:
Participants:

 Description   
Issue Status as of Jun 09, 2014

ISSUE SUMMARY
A mechanism called "idhack" chooses a different code path and fast-tracks query execution if the query is on _id without any other fields. Due to a major rewrite of the query engine for 2.6, the special case of queries with a projection does not yet use the "idhack" path and instead uses the regular code path which can be slower.

Example:

db.coll.find({{_id: 123}, {first_name: 1, last_name: 1})

This query on _id has a projection on {first_name: 1, last_name: 1}). In 2.6 this query would not use the fast "idhack" code path and would go through regular query planning instead, which is slower.

USER IMPACT
Users may find that queries on _id field with a projection can be slower in 2.6 than they were in 2.4.

WORKAROUNDS
None.

AFFECTED VERSIONS
Versions 2.6.0 and 2.6.1 are affected by this issue.

FIX VERSION
The fix is included in the 2.6.2 production release.

RESOLUTION DETAILS
The "idhack" runner now additionally supports queries with projections. This restores the behavior of version 2.4.

Original description

Re-enable using IDCursor runner for queries with projections.

> db.collection.find({_id: ObjectId("532b16caee361edb67169d7a")}, {_id:1}).explain()
{
	"cursor" : "IDCursor",
	"n" : 1,
	"nscannedObjects" : 0,
	"nscanned" : 1,
	"indexOnly" : true,
	"millis" : 0,
	"indexBounds" : {
		"_id" : [
			[
				ObjectId("532b16caee361edb67169d7a"),
				ObjectId("532b16caee361edb67169d7a")
			]
		]
	},
	"server" : "crucible-2.local:27017"
}
> db.collection.find({_id: ObjectId("532b16caee361edb67169d7a")}, {x:1}).explain()
{
	"cursor" : "BtreeCursor _id_",
	"isMultiKey" : false,
	"n" : 1,
	"nscannedObjects" : 1,
	"nscanned" : 1,
	"nscannedObjectsAllPlans" : 1,
	"nscannedAllPlans" : 1,
	"scanAndOrder" : false,
	"indexOnly" : false,
	"nYields" : 0,
	"nChunkSkips" : 0,
	"millis" : 0,
	"indexBounds" : {
		"_id" : [
			[
				ObjectId("532b16caee361edb67169d7a"),
				ObjectId("532b16caee361edb67169d7a")
			]
		]
	},
	"server" : "crucible-2.local:27017",
	"filterSet" : false
}



 Comments   
Comment by Githook User [ 06/Jun/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13337 support queries with projections in the idhack runner

(cherry picked from commit 10d8b3d7984a4abf0d8f80562d426d2f5f0707c3)

Conflicts:
src/mongo/db/query/idhack_runner.cpp
Branch: v2.6
https://github.com/mongodb/mongo/commit/5dfc754e10bc411b0d23b6ec1bdadfe3c72ad91c

Comment by Githook User [ 16/May/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13337 lite parsed query should set _showDiskLoc
(cherry picked from commit b0c0f83c4ca843412c991db3b21262be8ea78970)
Branch: v2.6
https://github.com/mongodb/mongo/commit/c26b53eaf60fdaa1413285a0892b782b33a9cf03

Comment by Githook User [ 14/May/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13337 lite parsed query should set _showDiskLoc
Branch: master
https://github.com/mongodb/mongo/commit/b0c0f83c4ca843412c991db3b21262be8ea78970

Comment by David Storch [ 06/May/14 ]

We have benchmarked this change in order to evaluate its impact for simple id queries with projections. See below for the results for both simple inclusion projections (e.g. {a: 1, b: 1}) and exclusion projections (e.g. {a: 0, b: 0}).

  2.6 without patch, inclusion 2.6 with patch, inclusion 2.4 inclusion 2.6 without patch, exclusion 2.6 with patch, exclusion 2.4 exclusion
Trial 1 (sec) 9.506050 7.720410 8.853624 12.528793 10.501580 8.714083
Trial 2 (sec) 9.555023 7.720830 8.770679 12.562265 10.624647 8.712911
Trial 3 (sec) 9.612263 7.719071 8.870323 12.577686 10.756626 8.645840
Trial 4 (sec) 9.573257 7.740221 8.787689 12.759174 10.727458 8.747107
Trial 5 (sec) 9.627897 7.702650 8.834499 12.537416 10.633644 8.707033

The results suggest that the regression for simple id queries with simple inclusion projections in 2.6 is fixed with 10d8b3d7984a4abf0d. The patch results in about a 20% overall perf improvement. The patch also shows about 20% improvement for exclusion projections, but 2.6 is still slower than 2.4 for such queries.

Comment by Githook User [ 01/May/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13337 support queries with projections in the idhack runner
Branch: master
https://github.com/mongodb/mongo/commit/10d8b3d7984a4abf0d8f80562d426d2f5f0707c3

Comment by J Rassi [ 25/Mar/14 ]

dan@10gen.com: this will cause queries to never be covered by compound indexes that include _id. That is, this will force a query like find({a:1,_id:1},{a:1,_id:1}) to use the {_id:1} index and do a fetch, even if there exists a better index like {a:1,_id:1} which would cover the query. Are you sure this is a good idea?

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