ISSUE SUMMARY
In the specific case where a compound 2dsphere index exists and is multi-key (at least one indexed value is an array), the wrong query plans can be generated for $near queries and lead to unexpected query results. For example, results returned by a $near query may no longer be sorted by distance.
USER IMPACT
Incorrect query plans can lead to unexpected behavior, specifically in the case of $near the user may get back incorrectly sorted documents from their query.
WORKAROUNDS
If possible, change the index to another compound field (in combination with the location) so it is no longer a multi-key index.
AFFECTED VERSIONS
Versions 2.6.0 and 2.6.1 are affected by this issue.
FIX VERSION
The fix is included in the 2.6.2 production release.
RESOLUTION DETAILS
The query plan enumerator now first assigns a mandatory predicate (e.g. $geonear), before assigning further predicates according to the usual rules of multi-key indexes.
Original description
I have been running a geospatial query using a compound index.
After upgrading to MongoDB 2.6, the order of the result set has changed such that the results are no longer being sorted by distance for the following query:
db.properties.find({ "address.uppercase": { $regex: "^14529" }, "address.location": { $near: { $geometry: { type: "Point", coordinates: [ -122.2103, 47.6154 ] }}}})
The index on the properties collection is configured as:
{ "address.uppercase": 1, "address.location": "2dsphere" }
In 2.4, the query returned all addresses where "address.uppercase" starts with "14529", ordered by the address distance from location [ -122.2103, 47.6154 ].
After upgrading to 2.6, the same query now returns all addresses ordered by "address.uppercase", effectively making it impossible to perform a geospatial $near query on a compound index.
- is duplicated by
-
SERVER-14264 Compound index on 2dsphere and datetime very slow in 2.6.1 and different result than in 2.4.10
-
- Closed
-
- is related to
-
-
- Closed
-