Re: Speed up Clog Access by increasing CLOG buffers
От | Amit Kapila |
---|---|
Тема | Re: Speed up Clog Access by increasing CLOG buffers |
Дата | |
Msg-id | CAA4eK1LjL6OrCKBubTtwPZgcYdZJ6ytW=wsGPv+w2JLjo6Zxjg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Speed up Clog Access by increasing CLOG buffers (Amit Kapila <amit.kapila16@gmail.com>) |
Список | pgsql-hackers |
On Tue, Nov 17, 2015 at 5:18 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
On Tue, Nov 17, 2015 at 5:04 PM, Simon Riggs <simon@2ndquadrant.com> wrote:On 17 November 2015 at 11:27, Amit Kapila <amit.kapila16@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, ifyou think it is viable to reserve space in shared memory for this purpose, thenI 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 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.
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?
В списке pgsql-hackers по дате отправления: