[SERVER-70780] [CQF] Simplify redundant PathObj / impossible PathArr Created: 21/Oct/22 Updated: 12/Jun/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Percy | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | Ideas, bonsai-onboarding, optimization | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Optimization
|
||||||||
| Participants: | |||||||||
| Description |
|
Take this $elemMatch predicate:
It expands to this ABT:
The last 3 lines correspond to b: 2, c: 3. This predicate can only be true when applied to an object. So the extra PathObj / PathArr checks are redundant: we can replace them with true / false respectively. It's not enough to check for a PathGet however. A predicate like b: {$exists: false} can be true when applied to a non-object, because it uses PathDefault which can "catch" Nothing. Other nodes like this include PathConstant and PathLambda. |
| Comments |
| Comment by David Percy [ 01/Jun/23 ] |
|
Initially I thought we should solve this by adding an optimization that takes an ABT and simplifies it. But it looks kind of complicated to detect whether the PathObj is redundant:
This starts to resemble type checking, which we probably should think about more holistically. So instead, maybe we can look at how we translate $elemMatch to ABT, and try to avoid creating the redundant nodes in the first place. Maybe "object elemMatch" never needs the PathArr? Maybe that PathArr is only used for nested elemMatch? |