[SERVER-13677] Query planner should traverse through $all while handling $elemMatch object predicates Created: 22/Apr/14  Updated: 11/Jul/16  Resolved: 22/Apr/14

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: 2.6.0, 2.6.1-rc0
Fix Version/s: 2.6.1, 2.7.0

Type: Bug Priority: Major - P3
Reporter: David Storch Assignee: David Storch
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Operating System: ALL
Backport Completed:
Steps To Reproduce:

> t.drop();
> t.ensureIndex({'a.b.c.d': 1});
> t.find({z: 1, "a.b": {$elemMatch: {c: {$all: [{$elemMatch: {d: 0}}]}}}});

Participants:

 Description   
Issue Status as of April 30, 2014

ISSUE SUMMARY
Queries which have the format below fail when there's an index reaching into the deepest subfield. The format is an $elemMatch operator that has an $all descendent, which in turn has another $elemMatch inside:

db.coll.find({z: 1, "a.b": {$elemMatch: {c: {$all: [{$elemMatch: {d: 0}}]}}}})

USER IMPACT
Low user impact due to the very specific format of the query required to trigger the bug.

WORKAROUNDS
If the $all operator is rewritten as an $and this issue is not triggered:

db.coll.find({z: 1, "a.b": {$elemMatch: {$and: [{c: [{$elemMatch: {d: 0}}]}]}}})

RESOLUTION
The bug arose from the query planner failing to consider predicates nested inside an $elemMatch-$all-$elemMatch chain. The planner logic was adjusted so that these predicates are no longer ignored.

AFFECTED VERSIONS
Version 2.6.0 is affected by this issue.

PATCHES
The patch is included in the 2.6.1 production release.

Original description

See the code here:

https://github.com/mongodb/mongo/blob/a7f594977627996aa8731e936ef9c3801d512fc0/src/mongo/db/query/planner_access.cpp#L484-L497

This function collects predicates from inside an $elemMatch object. Right now it traverses deeply through AND nodes and other ELEM_MATCH_OBJECT nodes. It should also traverse deeply through ALL. Failing to do so means that the access planner might miss predicates which are tagged to use the index, and hence fail to properly build the access plan.



 Comments   
Comment by Githook User [ 30/Apr/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13677 traverse through ALL when finding predicates inside elemMatch object
(cherry picked from commit 54bdb39ba62c25ef59221fcab866501c02a06047)
Branch: v2.6
https://github.com/mongodb/mongo/commit/6a900b9d4f43f866c1762247689c60944889ce08

Comment by Githook User [ 22/Apr/14 ]

Author:

{u'username': u'dstorch', u'name': u'David Storch', u'email': u'david.storch@10gen.com'}

Message: SERVER-13677 traverse through ALL when finding predicates inside elemMatch object
Branch: master
https://github.com/mongodb/mongo/commit/54bdb39ba62c25ef59221fcab866501c02a06047

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