Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time
Date
Msg-id CAA4eK1KJ_g-HyW3jmNr+hwcL0z8X0971RqrccW2gTPksbAC6+g@mail.gmail.com
Whole thread Raw
In response to Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: Transaction commits VS Transaction commits (with parallel) VSquery mean time
List pgsql-hackers
On Wed, Apr 3, 2019 at 10:45 AM Haribabu Kommi <kommi.haribabu@gmail.com> wrote:
>
> Thanks for the review.
>
> While changing the approach to use the is_parallel_worker_flag, I thought
> that the rest of the stats are also not required to be updated and also those
> are any way write operations and those values are zero anyway for parallel
> workers.
>
> Instead of expanding the patch scope, I just changed to avoid the commit
> or rollback stats as discussed, and later we can target the handling of all the
> internal transactions and their corresponding stats.
>

The patch looks good to me.  I have changed the commit message and ran
the pgindent in the attached patch.  Can you once see if that looks
fine to you?  Also, we should backpatch this till 9.6.  So, can you
once verify if the change is fine in all bank branches?   Also, test
with a force_parallel_mode option.  I have already tested it with
force_parallel_mode = 'regress' in HEAD, please test it in back
branches as well.


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

Attachment

pgsql-hackers by date:

Previous
From: "Tsunakawa, Takayuki"
Date:
Subject: RE: Re: reloption to prevent VACUUM from truncating empty pages atthe end of relation
Next
From: Andres Freund
Date:
Subject: Re: Refactoring the checkpointer's fsync request queue