Is this a TODO?
---
Florian G. Pflug wrote:
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Currently, we do not assume that either the childXids array, nor the xid
cache in the proc array are sorted by
Thanks for the feedback.
---
Florian G. Pflug wrote:
Bruce Momjian wrote:
Is this a TODO?
It's for from clear that avoing an exclusive ProcArray lock on subxact
abort will bring a measurable performance benefit, so
Bruce Momjian wrote:
Is this a TODO?
It's for from clear that avoing an exclusive ProcArray lock on subxact
abort will bring a measurable performance benefit, so probably not.
I've actually coded a prototype for this a few months ago, to
check if it would bring any benefit at all, though I
Florian G. Pflug [EMAIL PROTECTED] writes:
Currently, we do not assume that either the childXids array, nor
the xid cache in the proc array are sorted by ascending xid order.
I believe that we could simplify the code, further reduce the locking
requirements, and enabled a transaction to
Tom Lane wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
Currently, we do not assume that either the childXids array, nor the xid
cache in the proc array are sorted by ascending xid order. I believe that
we could simplify the code, further reduce the locking requirements, and
enabled a
Hi
I've already posted this idea, but I feel that I did explain it
rather badly. So here comes a new try.
Currently, we do not assume that either the childXids array, nor
the xid cache in the proc array are sorted by ascending xid order.
I believe that we could simplify the code, further reduce
