Enable SingleQE join with SegmentGeneralWorkers

[avamingli]

For a parallel join, we may benefit if gather SegmentGeneralWorkers to SingleQE.

Gather(SegmentGeneralWorkers) join SingleQE, return join locus: SingleQE. We may win if we are a parallel-aware join, SingleQE is on the inner side that means there is a chance to generate a parallel join under SingleQE. In this case, we have both side parallel and may benefit. See ex 5_P_2_2 in cbdb_parallel.sql

begin;
set local enable_parallel = on;
set local max_parallel_workers_per_gather = 4;
create table t1(a int, b int) with(parallel_workers=4);
create table t2(a int, b int) with(parallel_workers=4);
create table rt1(a int, b int) with(parallel_workers=4) distributed replicated;
insert into t1 select i, i from generate_series(1, 10000000) i;
insert into t2 select i, i from generate_series(1, 10000000) i;
insert into rt1 select i, i+1 from generate_series(1, 10000) i;
analyze t1;
analyze t2;
analyze rt1;
explain(costs off, locus) select * from rt1  join (select count(*) as c, sum(t1.a) as a  from t1 join t2 using(a)) t3 on t3.c = rt1.a;
                            QUERY PLAN                             
-------------------------------------------------------------------
 Parallel Hash Join
   Locus: Entry
   Hash Cond: (rt1.a = (count(*)))
   ->  Gather Motion 4:1  (slice1; segments: 4)
         Locus: Entry
         ->  Parallel Seq Scan on rt1
               Locus: SegmentGeneralWorkers
               Parallel Workers: 4
   ->  Parallel Hash
         Locus: Entry
         ->  Finalize Aggregate
               Locus: Entry
               ->  Gather Motion 12:1  (slice2; segments: 12)
                     Locus: Entry
                     ->  Partial Aggregate
                           Locus: HashedWorkers
                           Parallel Workers: 4
                           ->  Parallel Hash Join
                                 Locus: HashedWorkers
                                 Parallel Workers: 4
                                 Hash Cond: (t1.a = t2.a)
                                 ->  Parallel Seq Scan on t1
                                       Locus: HashedWorkers
                                       Parallel Workers: 4
                                 ->  Parallel Hash
                                       Locus: Hashed
                                       ->  Parallel Seq Scan on t2
                                             Locus: HashedWorkers
                                             Parallel Workers: 4
 Optimizer: Postgres query optimizer
(30 rows)
abort;

If not parallel-aware, we are not sure for the benefit and a simgle test shows lower performance, ex: parallel scan on replicated table and join with SingleQE which is a non-parallel plan.

SingleQE join Gather(SegmentGeneralWorkers), return join locus: SingleQE. We may win if gather to SingleQE no matter what parallel-aware is. SingleQE is outer side, there could be a parallel plan under it. So we may benefit even without a shared hash table. Let the planner decide.
See ex 2_P_5_2 in cbdb_parallel.sql

begin;
create table t1(a int, b int) with(parallel_workers=2);
create table rt1(a int, b int) with(parallel_workers=2) distributed replicated;
insert into t1 select i, i from generate_series(1, 100000) i;
insert into rt1 select i, i+1 from generate_series(1, 10000) i;
analyze t1;
analyze rt1;
set local enable_parallel = on;
explain(locus, costs off) select * from (select count(*) as a from t1) t1 left join rt1  on rt1.a = t1.a;
                      QUERY PLAN                      
------------------------------------------------------
 Parallel Hash Left Join
   Locus: Entry
   Hash Cond: ((count(*)) = rt1.a)
   ->  Finalize Aggregate
         Locus: Entry
         ->  Gather Motion 6:1  (slice1; segments: 6)
               Locus: Entry
               ->  Partial Aggregate
                     Locus: HashedWorkers
                     Parallel Workers: 2
                     ->  Parallel Seq Scan on t1
                           Locus: HashedWorkers
                           Parallel Workers: 2
   ->  Parallel Hash
         Locus: Entry
         ->  Gather Motion 2:1  (slice2; segments: 2)
               Locus: Entry
               ->  Parallel Seq Scan on rt1
                     Locus: SegmentGeneralWorkers
                     Parallel Workers: 2
 Optimizer: Postgres query optimizer
(21 rows)
abort;

The final locus may be elided to Entry if possible.

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🥳