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 the squeeze" 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 heap page.

So, the "squeeze" is not critical. This work grew out of CF-5556 where I move into the executor the equivalent logic as HeapDetermineColumnsInfo() and open the door to expanding the cases where we can have HOT updates. The two use cases for heap_update() are from heapam_tuple_update() called from the executor and simple_heap_update() called when updating a catalog 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 bits at the top of heap_update() into a common function used by both heapam_tuple_update() and simple_heap_update() and then fold HeapDetermineColumnsInfo() into simple_heap_update() entirely with a comment that says something like, "it would take 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 current patterns for catalog tuples a bit... well, they aren't what I'd choose to show people first as examples of programming excellence 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/piecemeal way.

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

-greg

> Greetings,
>
> Andres Freund