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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
group_update_clog_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
