On 2013-10-02 10:56:38 -0400, Robert Haas wrote:
> On Tue, Oct 1, 2013 at 1:56 PM, Andres Freund <andres@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...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
