On Mon, Mar 25, 2019 at 6:55 PM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
> On Sat, Mar 23, 2019 at 11:10 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> On Sat, Mar 23, 2019 at 9:50 AM Alvaro Herrera <alvherre@2ndquadrant.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?
>
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. As part of this thread, maybe we can
just fix the case of the parallel cooperating transaction.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com