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-27 01:23:03
Message-ID: CAJrrPGfYX_amYKy3X7G0h1K6haeGrHkj=yv-jrRN8=oxJqq46Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:

> On Mon, Mar 25, 2019 at 6:55 PM Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
> >
> >
> > Thanks to everyone for their opinions and suggestions to improve.
> >
> > Without parallel workers, there aren't many internal implementation
> > logic code that causes the stats to bloat. Parallel worker stats are not
> > just the transactions, it update other stats also, for eg; seqscan stats
> > of a relation. I also eagree that just fixing it for transactions may not
> > be a proper solution.
> >
> > Using of XID data may not give proper TPS of the instance as it doesn't
> > involve the read only transactions information.
> >
> > How about adding additional two columns that provides all the internal
> > and background worker transactions into that column?
> >
>
> I can see the case where the users will be interested in application
> initiated transactions, so if we want to add new columns, it could be
> to display that information and the current columns can keep
> displaying the overall transactions in the database. Here, I think
> we need to find a way to distinguish between internal and
> user-initiated transactions. OTOH, I am not sure adding new columns
> is better than changing the meaning of existing columns. We can go
> either way based on what others feel good, but I think we can do that
> as a separate head-only feature.

I agree with you. Adding new columns definitely needs more discussions
of what processes should be skipped and what needs to be added and etc.

> 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.

Regards,
Haribabu Kommi
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ryan Lambert 2019-03-27 01:39:37 Re: Fix XML handling with DOCTYPE
Previous Message Yugo Nagata 2019-03-27 01:20:54 Re: Improvement of installation document