[SERVER-10801] Allow compound geo indexes to be able to provide sort Created: 17/Sep/13 Updated: 28/Dec/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Geo, Querying |
| Affects Version/s: | 2.4.6 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jacob Ribnik | Assignee: | Backlog - Query Integration |
| Resolution: | Unresolved | Votes: | 15 |
| Labels: | qi-geo | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Assigned Teams: |
Query Integration
|
||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||
| Description |
|
I have a user with a collection of documents with points and timestamps. He performs a geo query on the points and a sort on the timestamps. I thought it would be useful to build a compound index with timestamp first and position second (timestamp_-1_position_2dsphere) and use that in the sort. However, the explain shows that the sort does not recognize that the timestamp is first in the index and instead goes straight to an S2Cursor. I recreated the user environment with the following javascript:
and executed the following query and explain:
As you can see an S2Cursor was used, scanAndOrder is true, and it does not appear to use the timestamp index. It is perfectly happy however to use timestamp as a single index. |
| Comments |
| Comment by Donald Venable [ 30/Aug/17 ] |
|
Is this still an issue? This is a use-case we're interested in. $nearSphere returns quick, but incorrect results (only uses sort), $geoWithin is very slow. |
| Comment by J Rassi [ 13/May/14 ] |
|
|
| Comment by Daniel Pasette (Inactive) [ 03/Oct/13 ] |
|
This is a limitation of the current query system. You cannot currently use the non-geo portion of a compound 2dsphere index to perform a sort. It will scan all geo matches and do an in-memory sort of the results. |
| Comment by Marco Biagi [ 03/Oct/13 ] |
|
I agree that it was duplicate with my issue. But please note that in my case was an integer/float, not a timestamp. Keep it in mind when solving this issue. |