Re: Expanding HOT updates for expression and partial indexes

On Tue, Mar 24, 2026, at 3:44 PM, Nathan Bossart wrote:
> On Tue, Mar 24, 2026 at 02:02:07PM -0400, Greg Burd wrote:
>> On Mon, Mar 23, 2026, at 2:39 PM, Nathan Bossart wrote:
>>> On Tue, Mar 17, 2026 at 02:04:11PM -0400, Greg Burd wrote:
>>>> - *    INDEX_ATTR_BITMAP_SUMMARIZED    Columns included in summarizing indexes
>>>> + *    INDEX_ATTR_BITMAP_INDEXED        Columns referenced by indexes
>>>> + *    INDEX_ATTR_BITMAP_SUMMARIZED    Columns only included in summarizing indexes
>>>
>>>> -    Bitmapset  *summarizedattrs;    /* columns with summarizing indexes */
>>>> +    Bitmapset  *indexedattrs;    /* columns referenced by indexes */
>>>> +    Bitmapset  *summarizedattrs;    /* columns only in summarizing indexes */
>>>
>>> As before, the comment changes for the summarized-attr-related stuff seem
>>> unnecessary.
>> 
>> I disagree, the "only" is required to highlight the logic change here.
>> Before this patch summarized attrs could overlap with indexed attrs, now
>> it should not.  This makes the logic a bit easier later in
>> HeapUpdateHotAllowable().
>
> My bad, you are right.

Hey Nathan,

No worries, that's why we talk about it. :)

>> So, we go from 3 calls to RelationGetIndexAttrBitmap() to 1, or at most 2
>> when there's a summarizing index (which is frequently the case).

I meant to say that the common case (no summarizing indexes) we don't need more than the 1 bitmap, only in the less
commoncase do we even need to get the *only* summarized attrs from relcache.
 

>> This feels more logical, cleaner, and has less overhead but supports the
>> same HOT logic.
>
> Nice.

I'm happy that you agree!

> -- 
> nathan

best.

-greg