Feedback-ID: i675e48f3:Fastmail
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\))
Subject: Re: Expanding HOT updates for expression and partial indexes
From: Greg Burd <greg@burd.me>
In-Reply-To: <96b451774d927daffe7fe40d06447eabb06a8f3f.camel@j-davis.com>
Date: Thu, 9 Oct 2025 17:13:12 -0400
Cc: Nathan Bossart <nathandbossart@gmail.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF5548AB-3BD3-4B6D-B4C2-F2B5CAC2CE8A@burd.me>
References: <97f0aa72-f172-4673-8b04-533f022c3149@app.fastmail.com>
 <CF007F8C-5FCA-4FC5-A7EC-282F8C9D413C@greg.burd.me> <aObOLg3JsebbwjOU@nathan>
 <96b451774d927daffe7fe40d06447eabb06a8f3f.camel@j-davis.com>
To: Jeff Davis <pgsql@j-davis.com>
Archived-At: 
 <https://www.postgresql.org/message-id/BF5548AB-3BD3-4B6D-B4C2-F2B5CAC2CE8A%40burd.me>
Precedence: bulk


> On Oct 9, 2025, at 3:08=E2=80=AFPM, Jeff Davis <pgsql@j-davis.com> =
wrote:
>=20
> On Wed, 2025-10-08 at 15:48 -0500, Nathan Bossart wrote:
>>> The theory being that
>>> my new code using the old/new tts to form and test the index tuples
>>> resulting from executing expressions was using the resultsRelInfo
>>> struct
>>> created during plan execution, not the information found on the
>>> page,
>>> and so was safe without the lock.
>>=20
>> An open question (at least from me) is whether this is safe.  I'm not
>> familiar enough with this area of code yet to confidently determine
>> that.

Hey Jeff,

Thanks for the nudge at PGConf.dev in NYC and for the follow-up here.

> The optimization requires that the expression evaluates to the same
> thing on the old and new tuples. That determination doesn't have
> anything to do with a lock on the buffer, so long as the old tuple
> isn't pruned away or something. And clearly it won't be pruned, =
because
> we're in the process of updating it, so we have a snapshot that can =
see
> it.

Right, I test that the expression on the index evaluates to the same
value when forming an index tuple for old/new slots.

> There might be subtleties in other parts of the proposal, but the =
above
> determination can be made safely without a buffer lock.
>=20
>>=20
>>> I added a reloption "expression_checks" to disable this new code
>>> path.=20
>>> Good idea or bad precedent?
>>=20
>> If there are cases where the added overhead outweighs the benefits
>> (which
>> seems like it must be true some of the time), then I think we must
>> have a
>> way to opt-out (or maybe even opt-in).  In fact, I'd advise adding a
>> GUC to
>> complement the reloption so that users can configure it at higher
>> levels.
>=20
> I'll push back against this. For now I'm fine with developer options =
to
> make testing easier, but we should find a way to make this work well
> without tuning.

I'm aligned with this, the reloption evolved from a GUC and I'm more of
the opinion that neither should exist and that the overhead of this be
minimized and so require no tuning or consideration by the end user.

best.

-greg

> Regards,
> Jeff Davis