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 expansion. 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: http://www.postgresql.org/mailpref/pgsql-hackers
