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

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

> On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
> wrote:
> >
> > On 2019-Mar-23, Amit Kapila wrote:
> >
> > > I think some users might also be interested in the write transactions
> > > happened in the system, basically, those have consumed xid.
> >
> > Well, do they really want to *count* these transactions, or is it enough
> > to keep an eye on the "age" of some XID column? Other than for XID
> > freezing purposes, I don't see such internal transactions as very
> > interesting.
> >
>
> That's what I also had in mind. I think doing anything more than just
> fixing the count for the parallel cooperating transaction by parallel
> workers doesn't seem intuitive to me. I mean if we want we can commit
> the fix such that all supporting transactions by parallel worker
> shouldn't be counted, but I am not able to convince myself that that
> is the good fix. Instead, I think rather than fixing that one case we
> should think more broadly about all the supportive transactions
> happening in the various operations. Also, as that is a kind of
> behavior change, we should discuss that as a separate topic.
>

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?

Regards,
Haribabu Kommi
Fujitsu Australia