Обсуждение: Re: Expanding HOT updates for expression and partial indexes

Поиск
Список
Период
Сортировка

Re: Expanding HOT updates for expression and partial indexes

От
Laurenz Albe
Дата:
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



Re: Expanding HOT updates for expression and partial indexes

От
"Burd, Greg"
Дата:
On Feb 9, 2025, at 1:14 AM, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> 
> I think that the goal of this patch is interesting and desirable.

Thanks for taking a look at it. Which version did you prefer, v3 or v4?

> The greatest concern for me is the performance impact.

Agreed, I’m still looking for ways to minimize it (suggestions welcome).

> 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 can remove the GUC in favor of a reloption, that makes sense to me.

> Yours,
> Laurenz Albe

best,

-greg