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

On Mon, Mar 5, 2012 at 6:37 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
>
> 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.

Thanks for correcting me. That sounds better.

It does however, illustrate my next review comment which is that the
comments and README items are sorely lacking here. It's quite hard to
see how it works, let along comment on major design decisions. It
would help myself and others immensely if we could improve that.

Is there a working copy on a git repo? Easier than waiting for next
versions of a patch.

My other comments so far are

* some permutations commented out - no comments as to why
Something of a fault with the isolation tester that it just shows
output, there's no way to record expected output in the spec

Comments required for these points

* 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?

* Why do we need to expand multixact with flags? Can we avoid that in
some cases?

* Why do we need to store just single xids in multixact members?
Didn't understand comments, no explanation

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