On Tue, Mar 26, 2019 at 9:08 PM Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Mar 25, 2019 at 6:55 PM Haribabu Kommi <kommi.harib...@gmail.com> > wrote: > > > > > > 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. I agree with you. Adding new columns definitely needs more discussions of what processes should be skipped and what needs to be added and etc. > As part of this thread, maybe we can > just fix the case of the parallel cooperating transaction. > With the current patch, all the parallel implementation transaction are getting skipped, in my tests parallel workers are the major factor in the transaction stats counter. Even before parallelism, the stats of the autovacuum and etc are still present but their contribution is not greatly influencing the stats. I agree with you in fixing the stats with parallel workers and improve stats. Regards, Haribabu Kommi Fujitsu Australia
