[SERVER-4164] Compound key index bounds for an array of documents seem wrong Created: 27/Oct/11 Updated: 12/Sep/12 Resolved: 29/Oct/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Index Maintenance |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bernie Hackett | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
This is related to http://groups.google.com/group/mongodb-user/browse_thread/thread/9f08de0b3c3e1a13 Explain shows correct bounds for a query on an array of documents if the array only includes one document:
If you then insert another document that has more than one document in the array the bounds listed by explain seem wrong:
|
| Comments |
| Comment by Neil Sanchala [ 29/Feb/12 ] |
|
We just ran into this issue and were surprised to discover that reads had become slower by design. If the goal is to support m*n index keys per record in this case, wouldn't it also work to add that data to the index and query it normally? Given that 2.0 comes with a new index version anyway, the reindexes that people do for the new version could also have added in this new data. Also, can you add this to http://www.mongodb.org/display/DOCS/2.0+Release+Notes? It's an important behavior change. |
| Comment by Dominik Gehl [ 01/Nov/11 ] |
|
I did the tests and ... can't prove any slowdown between 2.0.0. and 2.0.1 ... |
| Comment by Aaron Staple [ 31/Oct/11 ] |
|
The difference in the index bounds described above happened between 1.8 and 2.0. If you are running into a slowdown you think is a different issue please file a separate ticket. |
| Comment by Dominik Gehl [ 31/Oct/11 ] |
|
Is there anything which has changed (most probably between 2.0.0 and 2.0.1) which could explain a slowdown in this type of queries ? |
| Comment by Aaron Staple [ 29/Oct/11 ] |
|
This has come up a couple times recently. The behavior is by design and new in 2.0. The basic issue is as follows: If we have an index {'a.x':1,'a.y':1}and document {a:[ {x:1,y:1}, {x:2,y:2}]} we support indexing this document and we do so with two index keys: {'a.x':1,'a.y':1} {'a.x':2,'a.y':2}However, if we have a query like {'a.x':1,'a.y':2}we still need to return the document but there is no complete index key corresponding to the query. If we used index bounds on both 'a.x' and 'a.y' to resolve this query we would not return the document. So we use the index bounds on the first field and not the second to ensure we return the proper results. For certain types of $elemMatch queries we could constrain both fields, but that hasn't been implemented. It is This behavior only occurs with multikey indexes where two index field names share a field prefix (here, the shared prefix between a.x and a.y is 'a'). So as workarounds you might consider changing the schema or using a non multikey index. |