On Wed, Oct 2, 2013 at 11:05 AM, Andres Freund <andres@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 <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...
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
