Re: index prefetching - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: index prefetching
Date
Msg-id CAH2-WzkFRoTjD9T8ykYDzOMxzGiWFqcAkbK8B=HjfpoMdM4E8A@mail.gmail.com
Whole thread
In response to Re: index prefetching  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: index prefetching
List pgsql-hackers
On Fri, Mar 27, 2026 at 8:35 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Attached is v18, which addresses the tricky issues I skipped in v17.

v19 is attached. It contains a few notable improvements over v18:

* The first commit (the one that simply moves code into the new
heapam_indexscan.c file) now moves heap_hot_search_buffer over there
as well.

Andres suggested this at one point, and I believe it wins us a small
but significant performance benefit.

> * The "Add UnlockBufferGetLSN utility function" commit now uses an
> atomic operation (in the common case where it actually drops the index
> page's pin), just like UnlockReleaseBuffer itself following Andres'
> commit f39cb8c011062d65e146c1e9d1aae221e96d8320 from today.

* v19 removes the "Add UnlockBufferGetLSN utility function" patch entirely.

Following Andres' commit f39cb8c0, this no longer seemed to help
performance (compared to just calling BufferGetLSNAtomic and
UnlockReleaseBuffer directly), so I removed it.

> I believe I have now acted on all of Andres' feedback, with one minor
> exception: Andres disliked how we use 'if (scan->xs_heapfetch)' to
> determine whether to use the scan's batch cache (we don't want to use
> it at all if the scan is ending). I just ran out of steam, so this
> version doesn't address the problem.

* v19 fixes this by adding a new helper function. This allows us to
pass down the required context (whether the scan is ending) to inform
the relevant batch recycling code whether it really should place its
caller's batch in the scan's cache (or whether it should just pfree it
right away).

As in previous versions, I'm including several extra read stream
patches to address various problems in that area. These problems, tied
to how index prefetching stresses the read stream that are new and not
encountered by existing read stream users. Andres wrote all of these
patches. Those aspects of the patch should be discussed on a new
thread dedicated to index prefetching-related read stream
enhancements: https://postgr.es/m/f3xxfrkafjxpyqxywcxricxgyizjirfceychyxsgn7bwjp5eda@kwbduhy7tfmu

(Though I'm also carrying some extra bug fix patches here, not
included on that other thread, to address preexisting read stream
bugs, albeit bugs highly unlikely to affect current read stream
users.)

--
Peter Geoghegan

Attachment

pgsql-hackers by date:

Previous
From: Srinath Reddy Sadipiralla
Date:
Subject: Re: Adding REPACK [concurrently]
Next
From: Andres Freund
Date:
Subject: Re: EXPLAIN: showing ReadStream / prefetch stats