[SERVER-8753] Query optimizer doesn't use hashed key in a query with sorting on a different indexed value Created: 27/Feb/13 Updated: 07/Mar/14 Resolved: 27/Feb/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.4.0-rc0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Thomas Adam | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Hi, if I execute a query like this: db.entries.find( {"u.$id":ObjectId("5124aa20dfee8fb462469370")}).sort({_id:1}) leads to a full table scan, because he don't use my hashed index on "u.$id". See discussion here: https://groups.google.com/d/topic/mongodb-user/ngxI9vkv8Y4/discussion |
| Comments |
| Comment by Aaron Staple [ 27/Feb/13 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Current specced query optimizer behavior is that a non btree index cursor will only be considered for a query if there are no candidate btree cursors. This is described in In the first example the _id:1 index is a candidate btree index, preventing use of a hashed index on 'u.$id'. I filed | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 27/Feb/13 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I was able to reproduce this without sharding involved.
|