-
Type: Improvement
-
Resolution: Done
-
Priority: Major - P3
-
Affects Version/s: 2.0.1
-
Component/s: Index Maintenance, Querying
-
Environment:linux ubuntu
-
Fully Compatible
While bumping from 1.8 to mongo 2.0.1, we noticed some query optimization seemed not to work anymore. After some laborious digging in our data, we found out a single document showing the issue.
Please open the attached .tgz. The tc.sh script will restore the document in a core.picture_set_pictures collection on a localhost:27017 mongo, setup an index, and explain a range query on a date embedded in a array of objects. The relevant section of the output shows.
"indexBounds" :
{ "votes.created_at" : [ [ ISODate("2010-10-31T13:37:20Z"), ISODate("292278995-01--2147483647T07:12:56.808Z") ] ] }The upper bound is completely aberrant, and as far as I can tell, nothing in the document justifies such a value. As a consequence, on the real database, this will scan half of the table for every request. On the contrary, 1.8.3 was showing the right upper bound. Please also note that as far as we can tell, our collections have other instances of documents raising the problem (that is, a collection with just this document will exhibit the issue, but just removing the doc from the collection is not enough for the issue to disappear).
- is depended on by
-
SERVER-3104 index bound improvements for elemMatch query on multikey index
- Closed
- is duplicated by
-
SERVER-6002 Query on same field with $gt/$gte and $lt/$lte ignores one end of the range
- Closed
-
SERVER-6720 Range query with compound multikey index scans more objects than needed
- Closed
-
SERVER-8135 Unused index-boundaries on multikey
- Closed
- related to
-
SERVER-4184 date max index bound value looks messed up in shell as IsoDate
- Closed