To handle semi join in parallel, we have enabled Parallel Semi join.
This commit introduces a new approach to process Semi Join Query in Parallel of MPP, enable DEDUP_SEMI and DEDUP_SEMI_REVERSE join in parallel to handle semi join cases which could be a win in MPP mode.

Allow to use RowIdExpr in paths to process SEMI join query in parallel, and we could use Broadcast Motion in parallel too.
If one of that tables is relatively smaller than another, that will be a big win.

Even Redistribute both side(in parallel-oblivious plan) and unique it in upper plans, it may be a win compared to a SemiJoin Nodes.

Performance

Test of case[0] three times with 10 parallel number.

Plan

Both parallel-oblivious and parallel-aware are enabled, for examples of parallel-aware case:

DEDUP_SEMI

select sum(foo.a) from foo where exists (select 1 from bar where foo.a = bar.b);
                                       QUERY PLAN                                        
-----------------------------------------------------------------------------------------
 Finalize Aggregate
   ->  Gather Motion 6:1  (slice1; segments: 6)
         ->  Partial Aggregate
               ->  HashAggregate
                     Group Key: (RowIdExpr)
                     ->  Redistribute Motion 6:6  (slice2; segments: 6)
                           Hash Key: (RowIdExpr)
                           Hash Module: 3
                           ->  Parallel Hash Join
                                 Hash Cond: (foo.a = bar.b)
                                 ->  Broadcast Workers Motion 6:6  (slice3; segments: 6)
                                       ->  Parallel Seq Scan on foo
                                 ->  Parallel Hash
                                       ->  Parallel Seq Scan on bar
 Optimizer: Postgres query optimizer
(15 rows)

DEDUP_SEMI_REVERSE

select sum(foo.a) from foo where exists (select 1 from bar where foo.a = bar.b);
                                           QUERY PLAN                                           
------------------------------------------------------------------------------------------------
 Finalize Aggregate
   ->  Gather Motion 6:1  (slice1; segments: 6)
         ->  Partial Aggregate
               ->  HashAggregate
                     Group Key: (RowIdExpr)
                     ->  Redistribute Motion 6:6  (slice2; segments: 6)
                           Hash Key: (RowIdExpr)
                           Hash Module: 3
                           ->  Parallel Hash Join
                                 Hash Cond: (bar.b = foo.a)
                                 ->  Parallel Seq Scan on bar
                                 ->  Parallel Hash
                                       ->  Broadcast Workers Motion 6:6  (slice3; segments: 6)
                                             ->  Parallel Seq Scan on foo
 Optimizer: Postgres query optimizer
(15 rows)

For DEDUP_SEMI or DEDUP_SEMI_REVERSE join, each process need a unique RowIdExpr to identify unique rows, which is assigned with a baseline when building paths.

It's ok for non-parallel plan, but in parallel mode there are multiple processes on same segment, RowIdExpr in not unique then. To enable that, add ParallelWorkerNumberOfSlice to identify worker id of a parallel plan of a slice.

When rowidexpr is used, it's executed by 48 bits and left other 16 bits for segment_id. In parallel mode, we have to make more room for parallel worker id within segment_id's bits. This is done during planner with checks, in case that there are many segments with many parallel workers (which rarely happens).

[0] DDL & DML

create table foo(a int)  with(parallel_workers=10)  distributed randomly;
create table bar(b int)  with(parallel_workers=10)  distributed randomly;
insert into foo select i from generate_series(1,10000000)i;
insert into bar select i from generate_series(1,100000000)i;
analyze foo;
analyze bar;
select sum(foo.a) from foo where exists (select 1 from bar where foo.a = bar.b);

Authored-by: Zhang Mingli [email protected]

fix #ISSUE_Number

Change logs

Describe your change clearly, including what problem is being solved or what feature is being added.

If it has some breaking backward or forward compatibility, please clary.

Why are the changes needed?

Describe why the changes are necessary.

Does this PR introduce any user-facing change?

If yes, please clarify the previous behavior and the change this PR proposes.

How was this patch tested?

Please detail how the changes were tested, including manual tests and any relevant unit or integration tests.

Contributor's Checklist

Here are some reminders and checklists before/when submitting your pull request, please check them:

• Make sure your Pull Request has a clear title and commit message. You can take git-commit template as a reference.
• Sign the Contributor License Agreement as prompted for your first-time contribution(One-time setup).
• Learn the coding contribution guide, including our code conventions, workflow and more.
• List your communication in the GitHub Issues or Discussions (if has or needed).
• Document changes.
• Add tests for the change
• Pass make installcheck
• Pass make -C src/test installcheck-cbdb-parallel
• Feel free to request cloudberrydb/dev team for review and approval when your PR is ready🥳