[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:
https://gist.github.com/2636220



 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.

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