[SERVER-14071] For queries with .sort(), bad non-blocking plan can be cached if there are zero results Created: 27/May/14 Updated: 18/Sep/15 Resolved: 19/Feb/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.1, 2.7.1 |
| Fix Version/s: | 2.6.9, 3.0.0-rc9, 3.1.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | David Storch |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Backport Completed: | |||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Suppose indexes {a:1} and {b:1} exist on a collection, and the user issues the following query:
The query planner will unconditionally choose (and cache) the plan using the {b:1} index if no documents match either the {a: {$gt: 0}} or {b: {$gt: 0}} predicates. This is because both the {a:1} index plan and the {b:1} index plan have the same "productivity", but the plan using {b:1} hits EOF first because it does not have a blocking SORT stage. Note that this issue is not limited to range predicates; it is reproducible with any bounds-generating predicates. Reproduce with the following:
Plan cache detailed info:
|
| Comments |
| Comment by Paul Nock [ 21/Apr/15 ] |
|
Thanks David, I created thanks |
| Comment by David Storch [ 20/Apr/15 ] |
|
pnock, thanks for reporting this issue. From the available information, it is difficult to determine the root cause of this issue. One hypothesis is that it is a duplicate of
Please let me know your preference for moving forward. Best, |
| Comment by Paul Nock [ 20/Apr/15 ] |
|
(I posted this at https://jira.mongodb.org/browse/SERVER-13866 too, not sure if I know enough to say for sure if it's the same thing...) I'm seeing something that looks like this with 2.6.9: , $orderby: { _id: 1 }} planSummary: IXSCAN { _id: 1 }ntoskip:0 nscanned:125454 nscannedObjects:125454 keyUpdates:0 numYields:0 locks(micros) r:181778 nreturned:0 reslen:20 181ms , , |
| Comment by Githook User [ 03/Mar/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |
| Comment by Githook User [ 19/Feb/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: (cherry picked from commit ae341c89d09b634047dd080af0f9e173e6d8b6e5) |
| Comment by Githook User [ 19/Feb/15 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |