Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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). .

...