Re: Transaction commits VS Transaction commits (with parallel) VS query mean time

From: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Transaction commits VS Transaction commits (with parallel) VS query mean time
Date: 2019-03-28 06:12:57
Message-ID: CAJrrPGd41Fk8UgsZkZbx7wTtQ2cPaW4nx-mw0G_mKSAb2fiF3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 27, 2019 at 11:27 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

> On Wed, Mar 27, 2019 at 6:53 AM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
> > On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >>
> >> As part of this thread, maybe we can
> >> just fix the case of the parallel cooperating transaction.
> >
> >
> > With the current patch, all the parallel implementation transaction are
> getting
> > skipped, in my tests parallel workers are the major factor in the
> transaction
> > stats counter. Even before parallelism, the stats of the autovacuum and
> etc
> > are still present but their contribution is not greatly influencing the
> stats.
> >
> > I agree with you in fixing the stats with parallel workers and improve
> stats.
> >
>
> I was proposing to fix only the transaction started with
> StartParallelWorkerTransaction by using is_parallel_worker flag as
> discussed above. I understand that it won't completely fix the
> problem reported by you, but it will be a step in that direction. My
> main worry is that if we fix it the way you are proposing and we also
> invent a new way to deal with all other internal transactions, then
> the fix done by us now needs to be changed/reverted. Note, that this
> fix needs to be backpatched as well, so we should avoid doing any fix
> which needs to be changed or reverted.
>

I tried the approach as your suggested as by not counting the actual
parallel work
transactions by just releasing the resources without touching the counters,
the counts are not reduced much.

HEAD - With 4 parallel workers running query generates 13 stats ( 4 * 3 +
1)
Patch - With 4 parallel workers running query generates 9 stats ( 4 * 2 +
1)
Old approach patch - With 4 parallel workers running query generates 1 stat
(1)

Currently the parallel worker start transaction 3 times in the following
places.
1. InitPostgres
2. ParallelWorkerMain (2)

with the attached patch, we reduce one count from ParallelWorkerMain.

Regards,
Haribabu Kommi
Fujitsu Australia

Attachment Content-Type Size
0001-Avoid-counting-parallel-worker-transactions-stats_v3.patch application/octet-stream 3.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Banck 2019-03-28 07:26:43 Re: Progress reporting for pg_verify_checksums
Previous Message Fabien COELHO 2019-03-28 06:07:22 RE: minimizing pg_stat_statements performance overhead