[DOCS-8779] $all now choose optimal condition not the first one Created: 07/Sep/16  Updated: 09/Nov/16  Resolved: 09/Nov/16

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 3.4.0

Type: Improvement Priority: Major - P3
Reporter: Yaoxing Zhang Assignee: Steve Renaker (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-16042 Optimise $all/$and to select smallest... Closed
Participants:
Days since reply: 7 years, 14 weeks, 1 day ago
Story Points: 0.5

 Description   

https://docs.mongodb.com/manual/reference/operator/query/all/#performance

Queries that use the $all operator must scan all the documents that match the first element in the $all expression. As a result, even with an index to support the query, the operation may be long running, particularly when the first element in the $all expression is not very selective.

With SERVER-16042 fixed I think it's not the case anymore



 Comments   
Comment by Githook User [ 09/Nov/16 ]

Author:

{u'username': u'steveren', u'name': u'Steve Renaker', u'email': u'steve.renaker@mongodb.com'}

Message: DOCS-8779: $all now chooses optimal condition not the first one

Signed-off-by: kay <kay.kim@10gen.com>
Branch: master
https://github.com/mongodb/docs/commit/0c380381ebbd38f885d8f1b803d08dafc9002f4b

Comment by David Storch [ 16/Sep/16 ]

ravind.kumar, it's probably sufficient to just delete it. This note is indeed out of date for all 3.2.x versions, as well as later patch releases of 2.6 and 3.0. If you were to replace it with anything, you could describe the new planning behavior introduced in SERVER-16042. Specifically, when there are multiple predicates over the leading field of a multikey index inside an $all or $and, the planner will generate and rank an alternative plan for each predicate.

Comment by Ravind Kumar (Inactive) [ 16/Sep/16 ]

david.storch looking at SERVER-16042 it seems this change is accurate - any additional info that might be desired?

Generated at Thu Feb 08 07:56:57 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.