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