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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
