public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jeff Davis <[email protected]>
To: Greg Burd <[email protected]>
To: pgsql-hackers <[email protected]>
Subject: Re: Expanding HOT updates for expression and partial indexes
Date: Sat, 14 Feb 2026 11:39:53 -0800
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

On Fri, 2026-02-13 at 16:06 -0500, Greg Burd wrote:
> Here's my thinking, this patch set can be thought of as:
> 
> a) moving HeapDetermineColumnsInfo() into the executor

This feels like the core of the series: moving the logic into the
executor make it possible to be smarter about whether HOT can be
applied or not.

I think that is a good direction to go. I don't think HOT is
fundamentally a heap concept because other AMs may do something similar
and would want similar information. There are two parts to the decision
of whether to use HOT: first, is there a logical change to the indexed
value; and second, does the AM need to break the change for some other
reason (e.g. the current page is full).

It seems reasonable to me that the executor is the right place for the
first check, because it can be more precise. The motivating example
here is a JSON document where one field is indexed and unrelated fields
are being updated, in which case we can still do a HOT update because
the indexed value isn't actually changing.

As far as the patch itself, it seems like you're moving a lot of code
out of heap_update() and into simple_heap_update() &
heapam_tuple_update(). Can you explain why that's needed? Perhaps I
just need to look closer.

> b) all that HOT nonsense
> 
> I feel that (a) has value even without (b), that removing a chunk of
> work from within an exclusive buffer lock to outside that lock is a
> Good Thing(TM) and could in this case result in more concurrency.

Right. It would be nice to see some numbers here, but moving work
outside of the buffer lock seems like a good idea.

> To that end, present to you a single patch that *only* does (a), it
> moves the logic of HeapDeterminColumnsInfo() into the executor and
> doesn't change anything else.  Meaning that what goes HOT today
> (without this patch), should continue to be HOT tomorrow (with this
> patch) and nothing else.

Why are there test diffs?

Also, does this move us (slightly) closer to PHOT?


Regards,
	Jeff Davis

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Expanding HOT updates for expression and partial indexes
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox