[SERVER-9925] Index covered binary prefix search Created: 13/Jun/13 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Index Maintenance, Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Critical - P2 |
| Reporter: | Nicholas Tang | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query Optimization
|
||||
| Participants: | |||||
| Description |
|
We need a way to do a binary prefix search on an existing field that's covered by an index so it can happen quickly in RAM. |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 15/Jan/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
To do for binary, need to change sort order of bindata | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Yuri Finkelstein [ 05/Jul/13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Yes, the performance of this query is very poor at the moment. If indeed $or will be as performant as $in that could be an acceptable solution. Please note that if the following would be supported
it would more more concise and readable. What I also asked in relaed ticket is for the ability to specify limit for each $prefix term match. Example:
This would return at most one document with _id having a binary prefix MD5_1, at most one document with _id having a binary prefix MD5_2, etc. Without the $limit feature the query would first return all documents with _id having a binary prefix MD5_1. If the number of them is high and exceed the limit on the cursor we would have a logical problem of how to resume the query on the same cursor. Again, the syntax is just schematic and is meant only to help express the point. How you folks end up expressing it is not important as long as the same capabilities are supported. Does it make sense? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 03/Jul/13 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This already works in current version.
Is the issue that $in can't be used and it has to be an $or operator? There is a separate ticket for making $or as performant as $or but this ticket is specifically about covered index queryability which seems to work. |