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.)
> 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 Haas||Date: 2012-02-23 23:59:11|
|Subject: Re: Initial 9.2 pgbench write results|
|Previous:||From: Peter van Hardenberg||Date: 2012-02-23 23:23:50|
|Subject: psql \i tab completion initialization problem on HEAD|