On Mon, Dec 21, 2020 at 8:16 AM Hou, Zhijie <houzj.f...@cn.fujitsu.com> wrote: > The cfbost seems complains about the testcase: > > Command exited with code 1 > perl dumpregr.pl > === $path ===\ndiff -w -U3 > C:/projects/postgresql/src/test/regress/expected/write_parallel.out > C:/projects/postgresql/src/test/regress/results/write_parallel.out > --- C:/projects/postgresql/src/test/regress/expected/write_parallel.out > 2020-12-21 01:41:17.745091500 +0000 > +++ C:/projects/postgresql/src/test/regress/results/write_parallel.out > 2020-12-21 01:47:20.375514800 +0000 > @@ -1204,7 +1204,7 @@ > -> Gather (actual rows=2 loops=1) > Workers Planned: 3 > Workers Launched: 3 > - -> Parallel Seq Scan on temp2 (actual rows=0 loops=4) > + -> Parallel Seq Scan on temp2 (actual rows=1 loops=4) > Filter: (col2 < 3) > Rows Removed by Filter: 1 > (14 rows) > @@ -1233,7 +1233,7 @@ > -> Gather (actual rows=2 loops=1) > Workers Planned: 3 > Workers Launched: 3 > - -> Parallel Seq Scan on temp2 (actual rows=0 loops=4) > + -> Parallel Seq Scan on temp2 (actual rows=1 loops=4) > Filter: (col2 < 3) > Rows Removed by Filter: 1 > (14 rows)
Thanks! Looks like the explain analyze test case outputs can be unstable because we may not get the requested number of workers always. The comment before explain_parallel_append function in partition_prune.sql explains it well. Solution is to have a function similar to explain_parallel_append, say explain_parallel_inserts in write_parallel.sql and use that for all explain analyze cases. This will make the results consistent. Thoughts? If okay, I will update the test cases and post new patches. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
