On Fri, 2026-02-13 at 16:06 -0500, Greg Burd wrote:
> Here's my thinking, this patch set can be thought of as:
>
> a) moving HeapDetermineColumnsInfo() into the executor
This feels like the core of the series: moving the logic into the
executor make it possible to be smarter about whether HOT can be
applied or not.
I think that is a good direction to go. I don't think HOT is
fundamentally a heap concept because other AMs may do something similar
and would want similar information. There are two parts to the decision
of whether to use HOT: first, is there a logical change to the indexed
value; and second, does the AM need to break the change for some other
reason (e.g. the current page is full).
It seems reasonable to me that the executor is the right place for the
first check, because it can be more precise. The motivating example
here is a JSON document where one field is indexed and unrelated fields
are being updated, in which case we can still do a HOT update because
the indexed value isn't actually changing.
As far as the patch itself, it seems like you're moving a lot of code
out of heap_update() and into simple_heap_update() &
heapam_tuple_update(). Can you explain why that's needed? Perhaps I
just need to look closer.
> b) all that HOT nonsense
>
> I feel that (a) has value even without (b), that removing a chunk of
> work from within an exclusive buffer lock to outside that lock is a
> Good Thing(TM) and could in this case result in more concurrency.
Right. It would be nice to see some numbers here, but moving work
outside of the buffer lock seems like a good idea.
> To that end, present to you a single patch that *only* does (a), it
> moves the logic of HeapDeterminColumnsInfo() into the executor and
> doesn't change anything else. Meaning that what goes HOT today
> (without this patch), should continue to be HOT tomorrow (with this
> patch) and nothing else.
Why are there test diffs?
Also, does this move us (slightly) closer to PHOT?
Regards,
Jeff Davis
