[SERVER-13611] Missing sort order for compound index leads to unnecessary in-memory sort Created: 16/Apr/14 Updated: 11/Jul/16 Resolved: 17/Apr/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.0 |
| Fix Version/s: | 2.6.1, 2.7.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Steve Briskin (Inactive) | Assignee: | David Storch |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Backport Completed: | |||||||||
| Participants: | |||||||||
| Description |
|
Issue Status as of April 18, 2014 ISSUE SUMMARY USER IMPACT WORKAROUNDS RESOLUTION AFFECTED VERSIONS PATCHES Original descriptionSuppose you have a compound index {a: 1, b: 1, c: 1, d: 1} and a query with point intervals over 'a' and 'b'. The index scan can provide the following sort orders (both ascending and descending):
The code as it stands considers all of these sort orders except for one: {c: 1}. Specifically, it misses prefixes of the sort orders which do not begin with the first field in the compound index. There appears to be a regression in the sort phase between 2.6.0 and 2.4.8.
In 2.4.8
In 2.6.0:
If the sort is changed to {timestamp : 1}to match the direction of the index, the query behaves as expected in 2.6.0.
Credit: danny.gottlieb@gmail.com |
| Comments |
| Comment by Rudi Wijaya [ 05/May/14 ] |
|
Related to : |
| Comment by Githook User [ 17/Apr/14 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |
| Comment by Githook User [ 17/Apr/14 ] |
|
Author: {u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}Message: |
| Comment by David Storch [ 16/Apr/14 ] |
|
For both the sorts on {timestamp: 1} and {timestamp: -1}, we are erroneously falling through to the "explode for scans" logic (see So there are actually two problems here:
|
| Comment by David Storch [ 16/Apr/14 ] |
|
This is a bug in how we check for the sort orders provided by index scans during sort analysis (see https://github.com/mongodb/mongo/blob/fad935606f3d7edc4bae30f8f15288a144b4785d/src/mongo/db/query/planner_analysis.cpp#L360-L373). We fail to recognize that we can get the desired sort order when it is a prefix of a sort order which the index scan claims to provide. As a result, the example query will work as expected if you drop the index on {group:1, rs:1, timestamp:1, _id : 1} and instead build an index on {group:1, rs:1, timestamp:1}. The bug is triggered by a trailing field in the index key pattern (in this case, the trailing "_id" field). |