[SERVER-5786] explain() shows non complete plan for sharded query when using compound key Created: 08/May/12 Updated: 11/Jul/16 Resolved: 13/Jun/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Kenny Gorman | Assignee: | Aaron Staple |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Participants: |
| Description |
|
If you specify a query with a compound key with the leading edge being the shard key, and the secondary predicate is _id, then the optimizer performs the proper plan (it doesn't federate the query), but reports only the secondary predicate index as being read, and doesn't indicate that the shard key index was read. The plan would presumably be: read the shard key index, then filter results for secondary key. But this isn't indicated in the plan itself. Here is a sample session: |
| Comments |
| Comment by Aaron Staple [ 13/Jun/12 ] |
|
Hi Kenny. I'm going to close this ticket. Please feel free to reopen if you have further questions. |
| Comment by Aaron Staple [ 24/May/12 ] |
|
Hi Kenny, The two fields of the {shardkey:111,_id:999}index are treated as unordered, and the query optimizer is free to use the index on either of those fields to resolve a query. Since the _id index is unique, it's generally going to be a good choice for an equality lookup. |