Parallel Full Join and Right Join

[avamingli]

Parallel Hash Join has been in PostgreSQL for a while, but FULL and RIGHT outer joins were
deliberately left out of the initial implementation — the per-batch barrier protocol had a
deadlock risk that nobody had solved yet. UPSTREAM finally cracked it by adding a dedicated scan
phase (PHJ_BATCH_SCAN): after all workers finish probing, one elected worker walks the hash
table looking for unmatched inner rows and emits them, while the rest move on to other batches
or finish early. It is a clean solution and the upstream fix is compact. We are in the process
of cherry-picking UPSTREAM into CBDB, and this PR brings in those three upstream commits as a
foundation.

Performance

Benchmark on a 3-segment cluster with parallel_workers = 2 per segment (6 workers total),
6 million rows per table, 50% row overlap between the two sides.

Query	Parallel	Serial	Speedup
FULL JOIN	4040 ms	6347 ms	1.57×
RIGHT JOIN	3039 ms	5568 ms	1.83×

Example plans (3 segments, parallel_workers=2):

PARALLEL FULL JOIN:

      -- FULL JOIN: result locus is HashedOJ with Parallel Workers: 2
      EXPLAIN(costs off, locus)
      SELECT count(*) FROM t1 FULL JOIN t2 USING (id);

       Finalize Aggregate
         Locus: Entry
         ->  Gather Motion 6:1  (slice1; segments: 6)
               ->  Partial Aggregate
                     Locus: HashedOJ
                     Parallel Workers: 2
                     ->  Parallel Hash Full Join
                           Locus: HashedOJ
                           Parallel Workers: 2
                           Hash Cond: (t1.id = t2.id)
                           ->  Parallel Seq Scan on t1
                                 Locus: HashedWorkers
                           ->  Parallel Hash
                                 ->  Parallel Seq Scan on t2
                                       Locus: HashedWorkers

PARALLEL RIGHT JOIN

      -- RIGHT JOIN: when t1 is larger the planner hashes the smaller t2
      --             and probes with t1; result locus HashedWorkers
      EXPLAIN(costs off, locus)
      SELECT count(*) FROM t1 RIGHT JOIN t2 USING (id);

       Finalize Aggregate
         Locus: Entry
         ->  Gather Motion 6:1  (slice1; segments: 6)
               ->  Partial Aggregate
                     Locus: HashedWorkers
                     Parallel Workers: 2
                     ->  Parallel Hash Right Join
                           Locus: HashedWorkers
                           Parallel Workers: 2
                           Hash Cond: (t1.id = t2.id)
                           ->  Parallel Seq Scan on t1
                                 Locus: HashedWorkers
                           ->  Parallel Hash
                                 ->  Parallel Seq Scan on t2
                                       Locus: HashedWorkers

On top of the upstream work, CBDB's distributed execution model needed its own adaptations.
The tricky part is what happens to the result of a parallel full outer join: in a distributed
cluster the NULL-extended rows for unmatched tuples can land on any segment, so the result
cannot carry a plain Hashed locus — it needs HashedOJ. Before this PR the distributed
planner simply rejected FULL and RIGHT joins from the parallel path entirely, so every
such query fell back to serial execution on all segments. The planner now accepts both join
types, assigns the correct HashedOJ locus to a full join's output, and — importantly —
remembers to carry the parallel_workers count on that locus. Without that last detail,
any aggregate or further join sitting above the full join would see a locus with zero workers
and silently go serial, wiping out the benefit.

There is also a crash fix bundled here. A parallel NOT IN subquery join (LASJ_NOTIN) has
a special fast path: the moment any inner row with a NULL key is found, the whole join can
return empty, so the worker exits early. The problem is that this early exit happened before
the worker ever attached to the probing barrier for the current batch. Later, during shutdown,
the code still tried to arrive-and-detach from that barrier, which had zero participants and
asserted. The fix is straightforward: skip the barrier call when the early-exit condition was
triggered.

Type of Change

• Bug fix (non-breaking change)
• New feature (non-breaking change)
• Breaking change (fix or feature with breaking changes)
• Documentation update

Breaking Changes

Test Plan

• Unit tests added/updated
• Integration tests added/updated
• Passed make installcheck
• Passed make -C src/test installcheck-cbdb-parallel

Impact

Performance:

User-facing changes:

Dependencies:

Checklist

• Followed contribution guide
• Added/updated documentation
• Reviewed code for security implications
• Requested review from cloudberry committers

Additional Context

CI Skip Instructions

---