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 equi-partitioned 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 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’s joined with an xchg-3, no other plan would be 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 prop-parallel abstract plan construct is used to make sure that the optimizer chooses the parallel scan with the native degree.
