...
R5'. All other NestedTupleSourceOperators in the subplan is inlined with the query plan rooted at O1.
This is an abstract example for the special rewriting mechanism described above:
Before rewriting:
--Op1
--Subplan{
--AggregateOp
--NestedOp
– Join (J1)
– ..... (L1)
--Nested-Tuple-Source
– ..... (R1)
}
--InputOp
.....
After rewriting:
-- Op1
– GroupBy v_lc_1, ..., v_lc_n Decor v_l1, ....v_ln {
– AggregateOp
– NestedOp
– Select v_new!=NULL
– Nested-Tuple-Source
}
--LeftOuterJoin (J1)
(left branch)
– Assign v_new=TRUE
– ...... (L1)
– InputOp
.....
(right branch)
– ..... (R1)
In the plan, v_lc_1, ..., v_lc_n are live "covering" variables at InputOp, while v_rc_1, ..., v_rc_n are their corresponding variables populated from the deepcopy of InputOp. "Covering" variables form a set of variables that can imply all live variables. v_l1, ....v_ln in the decoration part of the added group-by operator are all live variables at InputOp except the covering variables v_lc_1, ..., v_lc_n. In the current implementation, we use "covering" variables as primary key variables. In the next version, we will use the real primary key variables, which will fix ASTERIXDB-1168.
Here is a concrete example (optimizerts/queries/nested_loj2.aql). .
...