On Sun, Nov 29, 2015 at 1:47 AM, Jeff Janes <
jeff.janes@gmail.com> wrote:
>
> On Thu, Nov 26, 2015 at 11:32 PM, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> > On Tue, Nov 17, 2015 at 6:30 PM, Simon Riggs <
simon@2ndquadrant.com> wrote:
> >>
> >> On 17 November 2015 at 11:48, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> >>>
> >>>
> >>> I think in that case what we can do is if the total number of
> >>> sub transactions is lesser than equal to 64 (we can find that by
> >>> overflowed flag in PGXact) , then apply this optimisation, else use
> >>> the existing flow to update the transaction status. I think for that we
> >>> don't even need to reserve any additional memory. Does that sound
> >>> sensible to you?
> >>
> >>
> >> I understand you to mean that the leader should look backwards through the
> >> queue collecting xids while !(PGXACT->overflowed)
> >>
> >> No additional shmem is required
> >>
> >
> > Okay, as discussed I have handled the case of sub-transactions without
> > additional shmem in the attached patch. Apart from that, I have tried
> > to apply this optimization for Prepared transactions as well, but as
> > the dummy proc used for such transactions doesn't have semaphore like
> > backend proc's, so it is not possible to use such a proc in group status
> > updation as each group member needs to wait on semaphore. It is not tad
> > difficult to add the support for that case if we are okay with creating
> > additional
> > semaphore for each such dummy proc which I was not sure, so I have left
> > it for now.
>
> Is this proposal instead of, or in addition to, the original thread
> topic of increasing clog buffers to 64?
>
This is in addition to increasing the clog buffers to 64, but with this patch
(Group Clog updation), the effect of increasing the clog buffers will be lesser.