On Thu, 2025-02-06 at 22:24 +0000, Burd, Greg wrote:
> Attached find a patch that expands the cases where heap-only tuple (HOT) updates are possible
> without changing the basic semantics of HOT. This is accomplished by examining expression
> indexes for changes to determine if indexes require updating or not. A similar approach is
> taken for partial indexes, the predicate is evaluated and, in some cases, HOT updates are
> allowed.
>
> [...]
>
> Third, there is overhead to this patch, it is no longer a single simple bitmap test to choose
> HOT or not in heap_update(). Sometimes this patch will perform expensive additional checks
> and ultimately not go down the HOT path, new overhead with no benefit. Some expressions are
> more expensive than others to evaluate, there is no logic to adjust for that. The Surjective
> patch/email thread had quite a bit of discussion on this without resolution. I’ve chosen to
> add a GUC that optionally avoids the expression evaluation. I’m open to ideas here as well,
> addition of another GUC or removal of the one I’ve added. I’ve tried to avoid rechecking
> indexes for changes when possible.
I think that the goal of this patch is interesting and desirable.
The greatest concern for me is the performance impact. I think that a switch is warranted,
but I am not sure if it should be a GUC. Wouldn't it be better to have a reloption, so that
this can be configured per table? I am not sure if a global switch is necessary, but I am
not fundamentally against it.
Yours,
Laurenz Albe
