[SERVER-34759] Improve the planner to detect {$alwaysTrue: 1} to mean the same thing as {$and: []} and {}. Created: 30/Apr/18 Updated: 29/Oct/23 Resolved: 28/Apr/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | Peter Volk |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Assigned Teams: |
Query Optimization
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | QO 2023-05-01 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
As part of an enhancement to the optimization explored in
Conclusion of the discussion is that the $AlwaysTrue and $and[] should be "normalized" for all cases to {} as this is more robust in the optimizer (default case having no predicated at all). |
| Comments |
| Comment by Peter Volk [ 28/Apr/23 ] |
|
The resulting fix was to standardize the behavior's of $and and $or in the case they result in an always true statement. |
| Comment by Githook User [ 28/Apr/23 ] |
|
Author: {'name': 'Peter Volk', 'email': 'peter.volk@mongodb.com', 'username': 'HCSPete'}Message: |
| Comment by Charlie Swanson [ 17/Apr/23 ] |
|
peter.volk@mongodb.com yes I think we should aim to replace our "canonical always true" MatchExpression to be $alwaysTrue: 1 - right now I think we use either an empty BSON Object or $and: [] throughout much of the planner, so I'm not sure if this is practically achievable without massive changes. But I would hope that it is. |
| Comment by Peter Volk [ 17/Apr/23 ] |
|
charlie.swanson@mongodb.com Is the intention here to teach the planner to understand that $and: [] and $alwaysTrue:1 are the same thing or only optimize an $and[] statement to an $alwaysTrue:1 statement? The latter case would be consistent to the $or clauses as {$or: [\{a: 1}, \{$alwaysTrue: 1}]} is optimized to {$alwaysTrue: 1} (testcase: OrWithAlwaysTrueOptimizesToAlwaysTrue) and hence would result in the same plan. Then in a next step the planer would need to be checked if it evaluates isTriviallyTrue() consistently. This would be beneficial for the and[] and the or case when the optimized statement results to $alwaysTrue. |