Alvaro Herrera wrote:
> The main catch of the "simple" formulation of the patch is that we do
> the new GetMultiXactIdMembers call with the buffer lock held, which is a
> horrible idea from a concurrency point of view; it will make many cases
> where the optimization doesn't apply a lot slower. I think with some
> extra contortions we could fix that problem, but it's already quite ugly
> that we have a duplicate check for the are-we-already-a-multixact-locker
> so I reject the idea that this seemingly simple patch is any good. I
> much prefer the complex formulation, which is what I had to start with,
> and makes thing a bit less unclear(*).
Here's an updated version of this patch. This applies to 9.3 and 9.4 and
restores performance to what's in master, while being much less invasive
than what was committed to master. But more importantly, what it does
is reduce the typical size of multixacts.
Since the size of multixacts is so critical with regards to the problems
of members overrun, I think it is a good idea to reduce it. In master
we already have an equivalent of this optimization.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services