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

On Fri, Mar 22, 2019 at 10:04 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> On 2019-Mar-21, Robert Haas wrote:
>
> > 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.
>

Agreed, this is a clear problem and we can just fix this and move
ahead, but it is better if we spend some more time to see if we can
come up with something better. We might want to just fix this and
then deal with the second part of the problem separately along with
some other similar cases.

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

Yeah, we can do that but it is not as clear as the previous one. The
reason is that we do similarly start/commit transaction for various
operations like autovacuum, cluster, drop index concurrently, etc.
So, it doesn't sound good to me to just change this for parallel query
and leave others as it is.

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

It appears to me that the definition of what we want to display in
xact_commit/xact_rollback (for pg_stat_database view) is slightly
vague. For ex. does it mean that we will show only transactions
started by the user or does it also includes the other transactions
started internally (which you call implementation detail) to perform
the various operations? I think users would be more interested in the
transactions initiated by them. I think some users might also be
interested in the write transactions happened in the system,
basically, those have consumed xid.

I think we should decide what we want to do for all other internal
transactions that are started before fixing the second part of this
problem ("other transactions that parallel workers use internally").

Thanks, Robert and Alvaro to chime in as this needs some discussion to
decide what behavior we want to provide to users.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com