On Mon, Dec 21, 2020 at 8:16 AM Hou, Zhijie <houzj.fnst@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
