Re: foreign key locks, 2nd attempt

Excerpts from Simon Riggs's message of lun mar 05 15:28:59 -0300 2012:
> 
> On Mon, Feb 27, 2012 at 2:47 AM, Robert Haas <robertmhaas@gmail.com> wrote:

> > From a performance standpoint, we really need to think not only about
> > the cases where the patch wins, but also, and maybe more importantly,
> > the cases where it loses.  There are some cases where the current
> > mechanism, use SHARE locks for foreign keys, is adequate.  In
> > particular, it's adequate whenever the parent table is not updated at
> > all, or only very lightly.  I believe that those people will pay
> > somewhat more with this patch, and especially in any case where
> > backends end up waiting for fsyncs in order to create new mxids, but
> > also just because I think this patch will have the effect of
> > increasing the space consumed by each individual mxid, which imposes a
> > distributed cost of its own.
> 
> That is a concern also.
> 
> It's taken me a while reviewing the patch to realise that space usage
> is actually 4 times worse than before.

Eh.  You're probably misreading something.  Previously each member of a
multixact used 4 bytes (the size of an Xid).  With the current patch a
member uses 5 bytes (same plus a flags byte).  An earlier version used
4.25 bytes per multi, which I increased to leave space for future
expansion.

So it's 1.25x worse, not 4x worse.

-- 
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support