Re: Refactor how we form HeapTuples for CatalogTuple(Insert|Update)

On Fri, Jan 30, 2026, at 12:20 PM, Andres Freund wrote:
> Hi,

Hello, thanks for taking a peek at this one.

> Sorry for being a downer - but: Is the gain here really worth the squeeze?

You are certainly not wrong, there are a lot of changes in this patch set.  To be honest, I'm not sure if it is "worth
thesqueeze" either.
 

What this patch does: it removes the need to rediscover the set of indexed attributes that changed during catalog tuple
updates.

Impact of that change: as-yet-unmeasured performance gains due to not having to redo work while holding a lock on the
heappage.
 

So, the "squeeze" is not critical.  This work grew out of CF-5556 where I move into the executor the equivalent logic
asHeapDetermineColumnsInfo() and open the door to expanding the cases where we can have HOT updates.  The two use cases
forheap_update() are from heapam_tuple_update() called from the executor and simple_heap_update() called when updating
acatalog tuple.  The other patch set (5556) covers one side, this covers the other.
 

> This is a *lot* of changes just to avoid a bunch of comparisons when doing
> catalog changes.

I was working on 5556, trying to provide a more detailed performance analysis, considering how I might fold the common
bitsat the top of heap_update() into a common function used by both heapam_tuple_update() and simple_heap_update() and
thenfold HeapDetermineColumnsInfo() into simple_heap_update() entirely with a comment that says something like, "it
wouldtake a lot of churn to fix up all the places we're updating catalog tuples..." etc.
 

If I do that, then this patch set is optional and as you said likely not worth the squeeze.  That said, I do find our
currentpatterns for catalog tuples a bit... well, they aren't what I'd choose to show people first as examples of
programmingexcellence in Postgres.  But they work, and have done so for a long time and that's worth something.
 

Maybe down the road I can revisit this and revamp things a bit more completely and maybe do so in a more
incremental/piecemealway.
 

best, and thanks for taking the time to express your thoughts, :)

-greg

> Greetings,
>
> Andres Freund