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
