On Tue, Oct 1, 2013 at 1:56 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2013-10-01 10:07:19 -0400, Robert Haas wrote: >> - It seems that HeapSatisfiesHOTandKeyUpdate is now >> HeapSatisfiesHOTandKeyandCandidateKeyUpdate. Considering I think this >> was merely HeapSatisfiesHOTUpdate a year ago, it's hard not to be >> afraid that something unscalable is happening to this function. On a >> related node, any overhead added here costs broadly; I'm not sure if >> there's enough to worry about. > > Ok, I had to think a bit, but now I remember why I think these changes > are not really problem: Neither the addition of keys nor candidate keys > will add any additional comparisons since the columns compared for > candidate keys are a subset of the set of key columns which in turn are a > subset of the columns checked for HOT. Right?
TBH, my primary concern was with maintainability more than performance. On performance, I think any time you add code it's going to cost somehow. However, it might not be enough to care about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
