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
