Re: Speed up Clog Access by increasing CLOG buffers - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Speed up Clog Access by increasing CLOG buffers
Date
Msg-id CAA4eK1+_66KZxf8PA4xU21z7rhGz7==n7ytb-eVJWdhJDF+s+Q@mail.gmail.com
Whole thread Raw
In response to Re: Speed up Clog Access by increasing CLOG buffers  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Speed up Clog Access by increasing CLOG buffers  (Jeff Janes <jeff.janes@gmail.com>)
Re: Speed up Clog Access by increasing CLOG buffers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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.


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

pgsql-hackers by date:

Previous
From: Stefan Kaltenbrunner
Date:
Subject: Re: New email address
Next
From: Michael Paquier
Date:
Subject: Re: Error with index on unlogged table