[SERVER-5858] Special index types including hashed indexes not always used when they should be Created: 17/May/12 Updated: 11/Jul/16 Resolved: 19/Dec/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 2.3.2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kevin Matulef | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
If a special index type is hinted but is not considered "suitable", the code in QueryPlan::newCursor instantiates its own btree rather than just handing off to the custom "newCursor" code for that index. This is probably incorrect behavior (I believe the btree bounds that it comes up with can be incorrect for special indexes). One way to to fix this is to initialize "_type" earlier, and make sure the custom newCursor methods handle being used for unsuitable queries. |
| Comments |
| Comment by auto [ 16/Oct/12 ] |
|
Author: {u'date': u'2012-10-16T11:59:11-07:00', u'email': u'matulef@10gen.com', u'name': u'Kevin Matulef'}Message: |
| Comment by Kevin Matulef [ 15/Oct/12 ] |
|
Linking to |
| Comment by Kevin Matulef [ 15/Oct/12 ] |
|
Either my earlier description of this ticket is wrong, or this portion of the query optimizer has changed since I originally filed the ticket. Currently, it appears that hashed indexes are not getting used for $in queries (e.g. {a : {$in : [1,2]}}) even though they are considered "suitable" and they work just fine if you explicitly hint them. |
| Comment by Eliot Horowitz (Inactive) [ 20/May/12 ] |
|
I don't think this is a bug, but is actually correct. |