I tried to confirm the patch with the following configuration:
max_parallel_workers_per_gather = 2
autovacuum = off
----
postgres=# BEGIN;
BEGIN
postgres=# select xact_commit from pg_stat_database where datname = 'postgres';
xact_commit
-------------
118
(1 row)
postgres=# explain analyze select * from tab where b = 6;
QUERY PLAN
---------------------------------------------------------------------------------------
------------------------------------
Gather (cost=1000.00..102331.58 rows=50000 width=8) (actual time=0.984..1666.932 rows
=99815 loops=1)
Workers Planned: 2
Workers Launched: 2
-> Parallel Seq Scan on tab (cost=0.00..96331.58 rows=20833 width=8) (actual time=
0.130..1587.463 rows=33272 loops=3)
Filter: (b = 6)
Rows Removed by Filter: 3300062
Planning Time: 0.146 ms
Execution Time: 1682.155 ms
(8 rows)
postgres=# COMMIT;
COMMIT
postgres=# select xact_commit from pg_stat_database where datname = 'postgres';
xact_commit
-------------
119
(1 row)
---------
[Conclusion]
I have confirmed that with the patch (with autovacuum=off,
max_parallel_workers_per_gather = 2), the increment is only 1.
Without the patch, I have also confirmed that
the increment in xact_commit > 1.
It seems Amit also confirmed that this should be the case,
so the patch works as intended.
>> Is the same applied to parallel worker transaction
>> commits also?
>
> I don't think so. It seems to me that we should consider it as a
> single transaction.
However, I cannot answer if the consideration of parallel worker activity
as a single xact_commit relates to good performance.
But ISTM, with this improvement we have a more accurate stats for xact_commit.
Regards,
Kirk Jamison
