From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Speed up Clog Access by increasing CLOG buffers |
Date: | 2015-11-28 20:17:25 |
Message-ID: | CAMkU=1yk-ad3AkfQd8uWPFDYQR941v+uNWLtJEjjr5nA1D95AA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 26, 2015 at 11:32 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Tue, Nov 17, 2015 at 6:30 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>
>> On 17 November 2015 at 11:48, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-11-28 20:24:22 | Re: Errors in our encoding conversion tables |
Previous Message | Alvaro Herrera | 2015-11-28 15:13:58 | Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc. |