Re: foreign key locks, 2nd attempt

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks, 2nd attempt
Date: 2012-03-06 19:58:22
Message-ID: CA+U5nMJrp1pgeTpDTQAf2kud_XUzYa7y92G4i0o9jdQa5eWPZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 5, 2012 at 8:35 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:

>>> * Why do we need multixact to be persistent? Do we need every page of
>>> multixact to be persistent, or just particular pages in certain
>>> circumstances?
>>
>> Any page that contains at least one multi with an update as a member
>> must persist.  It's possible that some pages contain no update (and this
>> is even likely in some workloads, if updates are rare), but I'm not sure
>> it's worth complicating the code to cater for early removal of some
>> pages.
>
> If the multixact contains an xid and that is being persisted then you
> need to set an LSN to ensure that a page writes causes an XLogFlush()
> before the multixact write. And you need to set do_fsync, no? Or
> explain why not in comments...
>
> I was really thinking we could skip the fsync of a page if we've not
> persisted anything important on that page, since that was one of
> Robert's performance points.

We need to increase these values to 32 as well

#define NUM_MXACTOFFSET_BUFFERS 8
#define NUM_MXACTMEMBER_BUFFERS 16

using same logic as for clog.

We're using 25% more space and we already know clog benefits from
increasing them, so there's little doubt we need it here also, since
we are increasing the access rate and potentially the longevity.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-03-06 20:07:23 Re: Checksums, state of play
Previous Message Alvaro Herrera 2012-03-06 19:39:32 Re: foreign key locks, 2nd attempt