Feedback-ID: i675e48f3:Fastmail
MIME-Version: 1.0
Date: Mon, 16 Mar 2026 12:23:04 -0400
From: "Greg Burd" <greg@burd.me>
To: "Jeff Davis" <pgsql@j-davis.com>,
 "Nathan Bossart" <nathandbossart@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Message-Id: <b0404aab-65a1-4922-9cff-986163ad70bb@app.fastmail.com>
In-Reply-To: <811d6f42e5481935943556b692859aae9146d4c9.camel@j-davis.com>
References: <fc17cbe85c24ff9d3cf43bfb37e6ca0d483fb2b4.camel@j-davis.com>
 <e1d06b18-2ebb-466e-bc0f-5d426d17a32e@app.fastmail.com>
 <akciabcu3b2hchj7adxhu4kovfaozp2pcn2z7sdljfthxcyg4o@7e6sfyzipvyy>
 <b8e07500-587d-4360-8f9e-89b14d1c0edc@app.fastmail.com>
 <bce13827-5f98-4d79-b779-ac5fff2b7668@app.fastmail.com>
 <c435d703af02097ec19680c2f8d4479292a3d176.camel@j-davis.com>
 <9bb9bdd6-e1fe-48fe-837d-4d0289396f1c@app.fastmail.com>
 <bed3fd08-ebfd-4980-801e-bff245a27dd7@app.fastmail.com>
 <ff2276c5-28f7-4e09-a6ae-40137ceddb67@app.fastmail.com>
 <872b875c-0aa4-4269-9c84-532227b32361@app.fastmail.com>
 <abMjC0jifWB0cs5F@nathan>
 <91f4dbe2-21ed-49f3-bebe-270f9bbec9d5@app.fastmail.com>
 <811d6f42e5481935943556b692859aae9146d4c9.camel@j-davis.com>
Subject: Re: Expanding HOT updates for expression and partial indexes
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/b0404aab-65a1-4922-9cff-986163ad70bb%40app.fastmail.com>
Precedence: bulk


On Sun, Mar 15, 2026, at 5:11 PM, Jeff Davis wrote:
> On Thu, 2026-03-12 at 17:31 -0400, Greg Burd wrote:
>> Other than the heap_modify_tuple() calls I don't know of something
>> that allows for direct changes but that doesn't matter, 0002 will
>> scan and pick up those attributes even if we introduce a new
>> modification path in the future (as intended).

Hello Jeff, thanks for taking a look! :)

> Why do extra work in ExecBRUpdateTriggers() to eliminate the false
> negative case if we don't rely on it anyway? If we do need to rely on
> it in subsequent patches, then we need to be sure, right?

Later commits do currently rely on it, ExecUpdateModifiedIdxAttrs() uses it in the next commit (0003) to avoid reviewing indexed attributes that could not have possibly changed.  Imagine a table with a lot of indexes where updates only modify one or two at a time.  Why are we testing indexed attributes for changes in HeapDeterminColumnsInfo() that couldn't have changed?  The answer is that a) HeapDeterminColumnsInfo() lives in heap, not the executor (see patch 0003) so it has no ability to call ExecGetAllUpdatedCols(), and b) the set returned by ExecGetAllUpdatedCols() is sometimes incomplete.

I see (a) as something I fix in patch 0003 and (b) as an oversight (or bug).  I'll also argue that the overhead of checking for additional attributes in ExecBRUpdateTriggers() vs the overhead of checking all indexed attributes in HeapDeterminColumnsInfo() is net zero once patch 0003 is applied.

The argument to keep 0002 is both performance as much as correctness.  After 0002 and 0003 ExecUpdateModifiedIdxAttrs() replaces HeapDeterminColumnsInfo() and doesn't have to scan all indexed attributes anymore.  Relations with lots of indexed attributes but update patterns that only focus on subsets of those attributes will benefit as there will be fewer memcmp() calls when comparing datums.

What do we "need to be sure" of?  That ExecGetAllUpdatedCols() not really contains all attributes that its name implies?  I think it now does that after 0002, do you disagree?

> I guess I'm confused about whether 0002 is introducing a new guarantee
> or if it's just a convenient place to eliminate one source of false
> negatives.

I think it is a new guarantee that was implied before now but not required until 0003.  I think this change reduces overhead and helps to avoid some future security feature that depends on ExecGetAllUpdatedCols() to provide that guarantee.

Does that make sense?

> Regards,
> 	Jeff Davis

best.

-greg