Re: foreign key locks, 2nd attempt - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: foreign key locks, 2nd attempt
Date
Msg-id CA+U5nMJrp1pgeTpDTQAf2kud_XUzYa7y92G4i0o9jdQa5eWPZA@mail.gmail.com
Whole thread Raw
In response to Re: foreign key locks, 2nd attempt  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Mon, Mar 5, 2012 at 8:35 PM, Simon Riggs <simon@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: foreign key locks, 2nd attempt
Next
From: Robert Haas
Date:
Subject: Re: Checksums, state of play