Re: foreign key locks, 2nd attempt

Excerpts from Noah Misch's message of mié feb 22 14:00:07 -0300 2012:
>
> On Mon, Feb 13, 2012 at 07:16:58PM -0300, Alvaro Herrera wrote:

> On Mon, Jan 30, 2012 at 06:48:47PM -0500, Noah Misch wrote:
> > On Tue, Jan 24, 2012 at 03:47:16PM -0300, Alvaro Herrera wrote:
> > > * Columns that are part of the key
> > > Noah thinks the set of columns should only consider those actually referenced
> > > by keys, not those that *could* be referenced.
> >
> > Well, do you disagree? To me it's low-hanging fruit, because it isolates the
> > UPDATE-time overhead of this patch to FK-referenced tables rather than all
> > tables having a PK or PK-like index (often just "all tables").
>
> You have not answered my question above.

Sorry. The reason I didn't research this is that at the very start of
the discussion it was said that having heapam.c figure out whether
columns are being used as FK destinations or not would be more of a
modularity violation than "indexed columns" already are for HOT support
(this was a contentious issue for HOT, so I don't take it lightly. I
don't think I need any more reasons for Tom to object to this patch, or
more bulk into it. Both are already serious issues.)

In any case, with the way we've defined FOR KEY SHARE locks (in the docs
it's explicitely said that the set of columns considered could vary in
the future), it's a relatively easy patch to add on top of what I've
submitted. Just as the ALTER TABLE bits to add columns to the set of
columns considered, it could be left for a second pass on the issue.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support