[SERVER-68488] Estimate FilterNode with mixed sargable and non-sargable AND/OR children Created: 02/Aug/22 Updated: 08/Feb/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Timour Katchaounov | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | bonsai-ce | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query Optimization
|
||||||||
| Participants: | |||||||||
| Description |
|
In the general case, there may exist FilterNodes that are not sargable as a whole, but have individual AND/OR children that are sargable. For instance, fiven the expression (a > 5 OR b < 10) AND (c = 33) AND (d regex 'acme.*corp'), the first term is a disjunction that is non sargable (until This task makes sure that each individual child is evaluated via a histogram whenever possible. The task also adds tests for various combinations of sargable/non-sargable nodes. |
| Comments |
| Comment by Timour Katchaounov [ 26/Sep/22 ] |
|
There still will be queries that will mix sargable and non-sargable predicates. With time more and more predicates/expressions will become sargable, so it is good to have a generic way to handle that. I will change the example in the description. |
| Comment by Timour Katchaounov [ 20/Sep/22 ] |
|
In addition add an includeScalar flag to the API for heuristic estimation in order to use $elemMatch semantics for its estimation. We could start by assuming that ~80% of values of a field are arrays when we see an $elemMatch. |
| Comment by Timour Katchaounov [ 02/Aug/22 ] |
|
This task depends on SERVER-67498. |