[SERVER-14629] 2d index no longer supports exact match Created: 21/Jul/14 Updated: 10/Dec/14 Resolved: 21/Jul/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Geo |
| Affects Version/s: | 2.6.3 |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | Pep Martinez | Assignee: | Thomas Rueckstiess |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Description |
|
I'm managing a 10k x 10k planar grid, in which I wish to use a 2d index for distance calculations/queries. For that, each entry in this grid is a document with a 'loc' field with its coordinates. Such coordinates, therefore, are integers between 0 and 9999 inclusive. The index creation needs then to specify a 'min' and a 'max'. In v2.4, queries on exact coordinates work as expected, returning almost immediately, with nscanned:1:
After upgrading to v2.6.3, the same query performs a full scan:
I am not sure 2d indexes on such ranges are actually allowed... |
| Comments |
| Comment by Thomas Rueckstiess [ 21/Jul/14 ] |
|
Hi Pep, I spoke with one of our Geo engineers about this. The feature to query for exact matches with a 2d index has been removed intentionally in an attempt to clean up the Geo Framework and focus its features on geo-location queries (proximity, intersection, containment, ...). Unfortunately, the documentation hasn't been updated to reflect this change. I opened a DOCS ticket to fix that. As a work-around, you can use a regular index on {loc: 1} instead for exact matches. If you still rely on actual geo queries and don't want to keep both indices, another alternative may be to use $near queries with a small $maxDistance, so to only target a single grid point. Regards, |
| Comment by Thomas Rueckstiess [ 21/Jul/14 ] |
|
Hi Pep, I can reproduce the behavior you're seeing, even for smaller grids that would fit into the standard limits between -180,180 x -90,90. The issue seems to be that 2d-indices no longer allow for exact matches. We'll look into this further and update the ticket when we know more. Thanks for reporting. Regards, |