[SERVER-19999] $all with $elemMatch indexes first element regardless of predicate cardinality (regression) Created: 18/Aug/15 Updated: 07/Oct/15 Resolved: 30/Sep/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | 2.6.10, 3.0.0 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andrew Ryder (Inactive) | Assignee: | David Storch |
| Resolution: | Duplicate | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Steps To Reproduce: |
|
||||||||||||||||
| Sprint: | QuInt A (10/12/15) | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
The pattern of using key/value attributes and querying using $all and $elemMatch used to work really efficiently even when the cardinality of values for specific keys was not known. Since 2.6.10 and 3.0.* this pattern now only uses the first predicate regardless.
Shown below are two explain(true) outputs, the first is what is seen when run on 2.6.0 -> 2.6.9... notice there are 2 possible plans in the allPlans list:
The second explain is what is seen for the same query on 2.6.10+ (including all of 3.0). Notice that there is now only 1 plan considered, based exclusively on the first item in the $all array:
|
| Comments |
| Comment by David Storch [ 30/Sep/15 ] |
|
evan@dnanexus.com, we will evaluate the risk associated with backport to the 2.6 branch, but for the moment this is only scheduled as part of the 3.0.7 patch release. |
| Comment by Evan Worley [ 30/Sep/15 ] |
|
So this will not be back ported to 2.6? |
| Comment by David Storch [ 30/Sep/15 ] |
|
We are currently planning on moving forward with the following option (excerpted from my previous comment):
After investigation, this approach should be relatively easy to implement, and is not too "technically tricky", It should also be backportable, at least to the 3.0 branch. Note that the planned fix will apply not only to $all-$elemMatch queries, but to any $all or $and query (including implicit $and). I am closing this ticket as a duplicate of |
| Comment by Evan Worley [ 31/Aug/15 ] |
|
Wonderful, thanks David. |
| Comment by David Storch [ 31/Aug/15 ] |
|
evan@dnanexus.com, understood. We are looking to make a targeted fix that will be suitable for backport to 3.0 and 2.6. Please keep in mind, however, that we can only evaluate backport once the fix is tested and pushed to the development branch. |
| Comment by Evan Worley [ 31/Aug/15 ] |
|
Thanks for all the info. I'm concerned that these fixes will not be back-ported. All of the mongo upgrades that we've done so far have required involved testing to ensure there are no major performance or functionality regressions. Given that we are on 2.6.9 now, 3.1 is probably many months away. If at all possible I would really like to see these fixes back ported at least to the 2.6 series. |
| Comment by David Storch [ 31/Aug/15 ] |
|
Some more context on this ticket: When working on I see three options for how we could handle this ticket:
I think #1 is feasible and backportable. Some queries will be slower, but this cost should be amortized due to plan caching. |