On Tue, Dec 22, 2020 at 12:32 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
> 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.
Attaching v14 patch set that has above changes. Please consider this
for further review.
With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com
