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 ofsub transactions is lesser than equal to 64 (we can find that byoverflowed flag in PGXact) , then apply this optimisation, else usethe existing flow to update the transaction status. I think for that wedon't even need to reserve any additional memory. Does that soundsensible 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
I think in that case what we can do is if the total number ofsub transactions is lesser than equal to 64 (we can find that byoverflowed flag in PGXact) , then apply this optimisation, else usethe existing flow to update the transaction status. I think for that wedon't even need to reserve any additional memory. Does that soundsensible to you?
pgsql-hackers by date:
Соглашаюсь с условиями обработки персональных данных