-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:
-
Query Optimization
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.