Cherry pick Rows out in EXPLAIN ANALYZE

[robozmey]

Cherry pick https://github.com/yezzey-gp/ygp/commit/1d4123048fbf5482c636eb193876d517edaaae81

Change logs

Add "Rows out" print in cdbexplain_showExecStats

create table tt (a int, b int) with(parallel_workers=2) distributed by (a);
insert into tt select * from generate_series(1,1000)a,generate_series(1,1000)b;
set enable_parallel = on;
set max_parallel_workers_per_gather = 2;
set gp_enable_explain_rows_out = on;

explain (analyze) select * from tt where a > b;

                                                            QUERY PLAN                                                            
----------------------------------------------------------------------------------------------------------------------------------
 Gather Motion 6:1  (slice1; segments: 6)  (cost=0.00..548.21 rows=28700 width=8) (actual time=2.000..54.000 rows=499500 loops=1)
   Rows out: 499500.00 rows avg x 1 workers from 1 segments, 499500 rows max (seg-1 worker0), 499500 rows min (seg-1 worker0).
   ->  Parallel Seq Scan on tt  (cost=0.00..213.38 rows=4783 width=8) (actual time=0.000..18.000 rows=85668 loops=1)
         Filter: (a > b)
         Rows Removed by Filter: 82531
         Rows out: 83250.00 rows avg x 6 workers from 3 segments, 86550 rows max (seg2 worker4), 80436 rows min (seg1 worker3).
 Planning Time: 0.151 ms
   (slice0)    Executor memory: 31K bytes.
   (slice1)    Executor memory: 85K bytes avg x 6x(0) workers, 110K bytes max (seg0).
 Memory used:  128000kB
 Optimizer: Postgres query optimizer
 Execution Time: 62.169 ms
(12 rows)

Why are the changes needed?

"Rows out" is useful for auto explain

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?

This feature tests in regression gp_explain test

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🥳

[CLAassistant]

All committers have signed the CLA.

[robozmey]

Do we have a Parallel Plan test(ex: cbdb_parallel.sql) to ensure the output is as expected?

I'm not sure what we need Parallel Plan test, but I expanded gp_explain.sql test

[avamingli]

Do we have a Parallel Plan test(ex: cbdb_parallel.sql) to ensure the output is as expected?

I'm not sure what we need Parallel Plan test, but I expanded gp_explain.sql test

In GPDB, there is one process executed the Slice on each segment. And explain use the statistic of that gang of QEs to compute the results. In CBDB, we have Parallel feature. For a parallel plan, there may be multiple QEs execute the same Slice on each segment. We call them parallel workers.

See CBDB style README https://github.com/apache/cloudberry/blob/11333c0b4d3a4962b0a6610ceb5b6d7a12e45ec4/src/backend/optimizer/README.cbdb.parallel for more details. And most cases could be found in https://github.com/apache/cloudberry/blob/11333c0b4d3a4962b0a6610ceb5b6d7a12e45ec4/src/test/regress/sql/cbdb_parallel.sql

This is a significant difference between CBDB and GPDB.

In parallel plan cases, what do the statistic results should be? Do current codes compute results right or it's already as expected? Maybe the current codes don't need to do anything else more, but we should be clear about that. In any cases, there should be test cases to verify the explain output.

[fanfuxiaoran]

In parallel plan cases, what do the statistic results should be? Do current codes compute results right or it's already as expected? Maybe the current codes don't need to do anything else more, but we should be clear about that.

Yes, agree! Looks we don't a lot things for the parallel workers. Cloudberry uses motion to gather the slice result both from workers on different segments and from the parallel worker on same segment . So the EXPLAIN ANALYZE command can still work properly to collect results from all workers.

But we should confirm the EXPLAIN ANALYZE output format for the plan contains parallel workers. what should it be like?

 Rows out: 333333.33 rows avg x 3 workers, 1000000 rows max (seg1), 0 rows min (seg0).

Do we need to add the parallel worker info into this line? like

 Rows out: 333333.33 rows avg x 3 workers from xx segments?, 1000000 rows max (seg1 worker?), 0 rows min (seg0 worker?).

[avamingli]

@fanfuxiaoran Thanks for your analysis and verification.

Do we need to add the parallel worker info into this line? like

 Rows out: 333333.33 rows avg x 3 workers from xx segments?, 1000000 rows max (seg1 worker?), 0 rows min (seg0 wo

Sounds good, with a worker info is more reasonable of parallel plan.

[robozmey]

In parallel plan cases, what do the statistic results should be? Do current codes compute results right or it's already as expected? Maybe the current codes don't need to do anything else more, but we should be clear about that.

Yes, agree! Looks we don't a lot things for the parallel workers. Cloudberry uses motion to gather the slice result both from workers on different segments and from the parallel worker on same segment . So the EXPLAIN ANALYZE command can still work properly to collect results from all workers.

But we should confirm the EXPLAIN ANALYZE output format for the plan contains parallel workers. what should it be like?

 Rows out: 333333.33 rows avg x 3 workers, 1000000 rows max (seg1), 0 rows min (seg0).

Do we need to add the parallel worker info into this line? like

 Rows out: 333333.33 rows avg x 3 workers from xx segments?, 1000000 rows max (seg1 worker?), 0 rows min (seg0 worker?).

I added test for parallel plan (cbdb_plan.sql)

I added segment count, and worker ids for max/min

Rows out: 83250.00 rows avg x 6 workers from 3 segments, 86144 rows max (seg2 worker4), 80391 rows min (seg1 worker2).