On Thu, Nov 26, 2015 at 11:32 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Tue, Nov 17, 2015 at 6:30 PM, Simon Riggs <si...@2ndquadrant.com> wrote: >> >> On 17 November 2015 at 11:48, Amit Kapila <amit.kapil...@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? Thanks, Jeff -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
