Re: foreign key locks, 2nd attempt

On Thu, Feb 23, 2012 at 06:36:42PM -0300, Alvaro Herrera wrote:
>
> 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.)

That's fair.

> 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.

Agreed. Let's have that debate another day, as a follow-on patch.

Thanks for shedding this light.