[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:
Related
related to DOCS-3338 Improve $near and geoNear pages to me... Closed
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.
2. Run a find() or aggregate() using geoNear or geoWithin, after which a sort() should be applied on an indexed field, after which a limit() should be set.
3. Run explain on the query above and you'll see the index is not used, as scanAndOrder=true and the number of scanned objects is very high.

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,
Thomas

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,
Thomas

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.

Generated at Thu Feb 08 03:32:08 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.