Skip site navigation (1) Skip section navigation (2)

Re: foreign key locks, 2nd attempt

From: Noah Misch <noah(at)leadboat(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>,Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks, 2nd attempt
Date: 2012-02-23 23:57:47
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-02-23 23:59:11
Subject: Re: Initial 9.2 pgbench write results
Previous:From: Peter van HardenbergDate: 2012-02-23 23:23:50
Subject: psql \i tab completion initialization problem on HEAD

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group