On 2013-10-02 11:06:59 -0400, Robert Haas wrote: > On Wed, Oct 2, 2013 at 11:05 AM, Andres Freund <and...@2ndquadrant.com> wrote: > > On 2013-10-02 10:56:38 -0400, Robert Haas wrote: > >> 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. > > > > The easy alternative seems to be to call such a function multiple times > > - which I think is prohibitive from a performance POV. More radically we > > could simply compute the overall set/bitmap of differening columns and > > then use bms_is_subset() to determine whether any index columns/key/ckey > > columns changed. But that will do comparisons we don't do today... > > Yeah, there may be no better alternative to doing things as you've > done them here. It just looks grotty, so I was hoping we had a better > idea. Maybe not.
Imo the code now looks easier to understand - which is not saying much - than in 9.3/HEAD... Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
