[SERVER-13569] sort() after geoNear/geoWithin find/aggregate doesn't use the index Created: 13/Apr/14 Updated: 10/Dec/14 Resolved: 01/May/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 2.4.6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Abraham Lopez | Assignee: | Thomas Rueckstiess |
| Resolution: | Done | Votes: | 0 |
| Labels: | geoNear, geoWithin, sort, sorting | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Operating System: | ALL | ||||||||
| Steps To Reproduce: | 1. Take a big collection (more than 1,000,000 documents) with Points (geospatial data). Be sure a 2D or 2DSphere index is applied to the Point field. |
||||||||
| Participants: | |||||||||
| Description |
|
Sorting a result by a single field on a find() or aggregate() result that uses geoNear or geoWithin and limiting the result (e.g. to 1,000 documents) yields a very slow response time. Running explain shows scanAndOrder=true and a very high number of scanned documents. If you remove the geoNear/geoWithin and get the whole collection, the sort is very fast, and explain shows scanAndOrder=false and a number of low number of scanned documents, which is equal to the limit specified. |
| Comments |
| Comment by Thomas Rueckstiess [ 02/May/14 ] |
|
Hi Abraham, You're right, it isn't well documented and can be confusing. I'll request a change in our documentation to make this clearer. Thanks for pointing that out. Regards, |
| Comment by Abraham Lopez [ 02/May/14 ] |
|
Ok Thomas, I agree. However, I think it would be useful for other to specify this behavior on MongoDB's documentation, so they can expect indexes to not work on sorts on other columns when using geoNear. |
| Comment by Thomas Rueckstiess [ 01/May/14 ] |
|
Hi Abraham, I'm going to close this issue now as we haven't heard back from you and I believe Asya replied to your question. If this does not match your scenario feel free to re-open the ticket and provide the additional information Asya requested. Regards, |
| Comment by Asya Kamsky [ 13/Apr/14 ] |
|
Since $near or $geoNear always return results ordered by distance from the point, it doesn't make sense to use them when you want results sorted by another field. If you want to sort by a different attribute you would need to use $geoWithin. However, the index (assuming it's on geo, other field) cannot be used to sort the second field, only to filter by it. This is a limitation of compound indexes when your use of the first field is not equality - the second field is not in order and has to be sorted. If what I described does not match your scenario, please show an example document, indexes on the collection and show an explain() for a query (find) with geoWithin and sort on another attribute also in the index. |