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 <robertmh...@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

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

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to