Abstract plans for parallel processing

Partitioned tables scanned in parallel produce partitioned streams of tuples. Different operators have specific needs for parallel processing. For instance, in all joins, either both children must be equipartitioned, or one child must be replicated.

The abstract plan xchg operator forces the optimizer to repartition, on-the-fly, in n ways, its child-derived table. The abstract plan only gives the degree. The optimizer chooses the most useful partitioning columns and style (hash, range, list, or round-robin).

In the following example, assume that t1 and t2 are hash partitioned two ways and three ways on the join columns, and i_c21 is a local index:

select *
from t1, t2
where c11=c21

The following abstract plan repartitions t1 three ways, does a three-way parallel nl_join, serializes the results, and returns a single data stream to the client:

(xchg 1
  (nl_join
    (xchg 3
      (t_scan t1)
    )
    (i_scan i_c21 t2)
  )
)

It is not necessary to specify t2’s parallel scan. It is hash-partitioned three ways, and, as it is joined with an xchg-3, no other plan is legal.

The following abstract plan scans and sorts t1 and t2 in parallel, as each is partitioned, then serializes them for the m_join:

(m_join
    (xchg 1
        (sort
            (t_scan t1)
        )
    )
    (xchg 1
        (sort
            (t_scan t2)
        )
    )
)
(prop t1 (parallel 2))
(prop t2 (parallel 3))

The parallel abstract plan construct is used to make sure that the optimizer chooses the parallel scan with the native degree.