On Tue, Nov 17, 2015 at 5:18 PM, Amit Kapila <amit.kapil...@gmail.com> wrote:
> 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 mind? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
