Details
-
Improvement
-
Resolution: Unresolved
-
Major - P3
-
None
-
None
-
None
-
Query Optimization
Description
For the query,
find({"a.b.c": 1, "a.b.d": 1}) |
where there are non-multikey indexes on "a'" and "a.b", Bonsai might produce the following plan
Root [{p0}]
|
Filter []
|
| EvalFilter []
|
| | Variable [p10]
|
| PathGet [b] PathGet [d] PathTraverse [1] PathCompare [Eq] Const [1] |
Filter []
|
| EvalFilter []
|
| | Variable [p10]
|
| PathGet [b] PathGet [c] PathTraverse [1] PathCompare [Eq] Const [1] |
PhysicalScan [{'<root>': p0, 'a': p10}, c_8c978cf6-00f0-457e-baa4-a76eba34bbb6] |
|
|
|
|
[2] filter {(traverseF(getField(getField(s3, "b"), "d"), lambda(l101.0) { (move(l101.0) == 1L) }, false) ?: false)} |
[1] filter {(traverseF(getField(getField(s3, "b"), "c"), lambda(l101.0) { (move(l101.0) == 1L) }, false) ?: false)} |
[0] scan s2 none none none none none none none lowPriority [s3 = a] @"8c978cf6-00f0-457e-baa4-a76eba34bbb6" true false |
Note that the projection for "a" is shared between the two filter nodes as it is pushed down to the physical scan, but the projection for "a.b" is re-evaluated, once by each Filter node.
This plan could be improved by avoiding the duplicate getField("b") by inserting an EvaluationNode between the PhysicalScan and Filter to generate this projection. I think we should run such a rewrite after the memo phases.
Part of this ticket should also be to understand why the existing path fusion rewrites don't handle this case.