[SERVER-12219] Use of $isolated inhibits query by id runner selection Created: 31/Dec/13  Updated: 11/Jul/16  Resolved: 10/Jan/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: 2.5.5

Type: Bug Priority: Major - P3
Reporter: Andrew Morrow (Inactive) Assignee: David Storch
Resolution: Done Votes: 0
Labels: Performance
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

Run an _id query driven workload under 'perf top', and notice the IDHackRunner in the output. Re-run with $isolated, and note that the IDHackRunner goes away, and the QueryPlanner::plan function appears. Also, if you measure throughput, it is noticeably slower.

Participants:

 Description   

Normally, a query like

{ _id : 1 }

will be routed to the "id hack" query runner. However, if the query is marked isolated with

{ _id : 1, $isolated : 1 }

, then the query execution is routed through QueryPlanner::plan, rather than redirected to the id hack runner, which greatly reduces performance.



 Comments   
Comment by Githook User [ 10/Jan/14 ]

Author:

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

Message: SERVER-12219 allow idhack with $isolated

Signed-off-by: Matt Kangas <matt.kangas@mongodb.com>
Branch: master
https://github.com/mongodb/mongo/commit/dd17ec43de5d4a716995ef3ed57220dac62b382f

Comment by Andrew Morrow (Inactive) [ 09/Jan/14 ]

It is syntactically valid, so while it may be redundant for a query by _id, it should be harmless to specify it, but it currently is harmful. The alternative would be to forbid it, but on what basis?

Comment by Asya Kamsky [ 09/Jan/14 ]

$isolated doesn't make sense for a query by _id. the point of $isolated is to not yield between multiple document updates (for example). How can $isolated make sense with _id which by definition will only match one document?

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