On Tue, Nov 17, 2015 at 5:18 PM, Amit Kapila <amit.kapil...@gmail.com>

> On Tue, Nov 17, 2015 at 5:04 PM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
>> On 17 November 2015 at 11:27, Amit Kapila <amit.kapil...@gmail.com>
>> wrote:
>> We are trying to speed up real cases, not just benchmarks.
>>>> So +1 for the concept, patch is going in right direction though lets do
>>>> the full press-up.
>>> I have mentioned above the reason for not doing it for sub transactions,
>>> if
>>> you think it is viable to reserve space in shared memory for this
>>> purpose, then
>>> I can include the optimization for subtransactions as well.
>> The number of subxids is unbounded, so as you say, reserving shmem isn't
>> viable.
>> I'm interested in real world cases, so allocating 65 xids per process
>> isn't needed, but we can say is that the optimization shouldn't break down
>> abruptly in the presence of a small/reasonable number of subtransactions.
> 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.

I think this won't work as it is, because subxids in XidCache could be
on different pages in which case we either need an additional flag
in XidCache array or a separate array to indicate for which subxids
we want to update the status.  I don't see any better way to do this
optimization for sub transactions, do you have something else in

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

Reply via email to