Message-ID: <0a47ce53fa635787d36325b5ad7bac94cdca4246.camel@cybertec.at>
Subject: Re: Expanding HOT updates for expression and partial indexes
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: "Burd, Greg" <gregburd@amazon.com>, "pgsql-hackers@postgresql.org"
	 <pgsql-hackers@postgresql.org>
Date: Sun, 09 Feb 2025 07:14:49 +0100
In-Reply-To: <78574B24-BE0A-42C5-8075-3FA9FA63B8FC@amazon.com>
References: <78574B24-BE0A-42C5-8075-3FA9FA63B8FC@amazon.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/0a47ce53fa635787d36325b5ad7bac94cdca4246.camel%40cybertec.at>
Precedence: bulk

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 exam=
ining expression
> indexes for changes to determine if indexes require updating or not. A si=
milar 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 b=
itmap 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. So=
me expressions are
> more expensive than others to evaluate, there is no logic to adjust for t=
hat. The Surjective
> patch/email thread had quite a bit of discussion on this without resoluti=
on. I=E2=80=99ve chosen to
> add a GUC that optionally avoids the expression evaluation. I=E2=80=99m o=
pen to ideas here as well,
> addition of another GUC or removal of the one I=E2=80=99ve added. I=E2=80=
=99ve 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 swit=
ch is warranted,
but I am not sure if it should be a GUC.  Wouldn't it be better to have a r=
eloption, so that
this can be configured per table?  I am not sure if a global switch is nece=
ssary, but I am
not fundamentally against it.

Yours,
Laurenz Albe