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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(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-22 04:33:59
Message-ID: 20190322043359.GA1081@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Mar-21, Robert Haas wrote:

> I don't have a strong position on what the "right" thing
> to do here is, but I think if you want to know how many client
> transactions are being executed, you should count them on the client
> side, as pgbench does.

I think counting on the client side is untenable in practical terms.
They may not even know what clients there are, or may not have the
source code to add such a feature even if they know how. Plus they
would have to aggregate data coming from dozens of different systems?
I don't think this argument has any wings.

OTOH the reason the server offers stats is so that the user can know
what the server activity is, not to display useless internal state.
If a user disables an internal option (such as parallel query) and their
monitoring system suddenly starts showing half as many transactions as
before, they're legitimaly going to think that the server is broken.
Such stats are pointless.

The use case for those stats seems fairly clear to me: display numbers
in a monitoring system. You seem to be saying that we're just not going
to help developers of monitoring systems, and that users have to feed
them on their own.

> I agree that it's a little funny to count the parallel worker commit
> as a separate transaction, since in a certain sense it is part of the
> same transaction.

Right. So you don't count it. This seems crystal clear. Doing the
other thing is outright wrong, there's no doubt about that.

> But if you do that, then as already noted you have to next decide what
> to do about other transactions that parallel workers use internally.

You don't count those ones either.

> And then you have to decide what to do about other background
> transactions.

Not count them if they're implementation details; otherwise count them.
For example, IMO autovacuum transactions should definitely be counted
(as one transaction, even if they run parallel vacuum).

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2019-03-22 05:02:36 Re: [HACKERS] Block level parallel vacuum
Previous Message David Rowley 2019-03-22 04:20:07 Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name