Re: index prefetching

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Tomas Vondra <tomas(at)vondra(dot)me>, Alexandre Felipe <o(dot)alexandre(dot)felipe(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Georgios <gkokolatos(at)protonmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: index prefetching
Date: 2026-03-12 19:44:32
Message-ID: CAH2-Wzn1j2a0p3OqmqrV6zADtWA_QpG82U6F9yCYG1Uschm_fA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 10, 2026 at 6:29 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> This seems pretty unrelated to my concern. I have a problem with the fact
> that heapam knows which specific resources need to be held (&released) to
> prevent concurrency issues during an index only scan. I am *NOT* concerned
> with there needing to be a pin and heapam triggering the release of that
> resource.

Attached v13 does things this way.

All index AMs that use amgetbatch must register a new amreleasebatch
callback in v13. This callback releases any buffer pin held as an
interlock against unsafe concurrent TID recycling by VACUUM -- at
least for nbtree and hash. The buffer itself is now stored in the
portion of each batch used as opaque index AM state, so nothing stops
other index AMs that support amgetbatch in the future from using a
different kind of interlock, from holding multiple pins instead of
just one, etc.

We have a generic policy that determines (at the level of each scan)
whether an interlock is required at all. If an interlock isn't
required, index AMs will drop both their lock and pin together.
Otherwise, they will only drop the lock, and only drop the
pin/abstract interlock when the new amreleasebatch callback is called
by the table AM. Our policy is to assume that we don't need a TID
recycling interlock except during index-only scans and non-MVCC scans
(regardless of the table AM and index AM involved).

Separately, I removed the requirement that amgetbatch index AMs
support Valgrind instrumentation requests like those nbtree has long
supported. And I removed all such instrumentation from the hash index
AM.

> > Is this purely because of the potential to
> > disrupt the read stream's management of the backend's buffer pin
> > limit?
>
> I'm not particularly bothered by a small number of extra buffer pins,
> particularly for AMs other than nbtree. They won't cause issues in any real
> world setups.

Okay. Then I don't think that we need to do anything here. As you
know, nbtree never holds buffer pins for its own internal purposes.
The hash index AM continues to hang on to up to 2 extra buffer pins
for its own purposes, just like on master.

--
Peter Geoghegan

Attachment Content-Type Size
v13-0019-Make-hash-index-AM-use-amgetbatch-interface.patch application/octet-stream 41.8 KB
v13-0016-WIP-read_stream-Prevent-distance-from-decaying-t.patch application/octet-stream 2.9 KB
v13-0018-Add-fake-LSN-support-to-hash-index-AM.patch application/octet-stream 14.0 KB
v13-0001-Extract-fake-LSN-infrastructure-from-GiST-index-.patch application/octet-stream 16.6 KB
v13-0017-WIP-aio-io_uring-Use-IO-size-not-IO-queue-to-tri.patch application/octet-stream 4.1 KB
v13-0015-WIP-read_stream-Only-increase-distance-when-wait.patch application/octet-stream 2.3 KB
v13-0013-WIP-aio-io_uring-Allow-IO-methods-to-check-if-IO.patch application/octet-stream 4.6 KB
v13-0014-bufmgr-Return-whether-WaitReadBuffers-needed-to-.patch application/octet-stream 2.8 KB
v13-0012-WIP-read_stream-Issue-IO-synchronously-while-in-.patch application/octet-stream 2.0 KB
v13-0011-Don-t-wait-for-already-in-progress-IO.patch application/octet-stream 20.6 KB
v13-0007-Limit-get_actual_variable_range-to-scan-three-in.patch application/octet-stream 9.4 KB
v13-0008-Add-heapam-index-scan-I-O-prefetching.patch application/octet-stream 43.4 KB
v13-0010-Make-buffer-hit-helper.patch application/octet-stream 6.0 KB
v13-0009-Use-ExecSetTupleBound-hint-during-index-scans.patch application/octet-stream 10.9 KB
v13-0006-Add-interfaces-that-enable-index-prefetching.patch application/octet-stream 250.2 KB
v13-0004-Make-IndexScanInstrumentation-a-pointer-in-execu.patch application/octet-stream 9.1 KB
v13-0005-heapam-Track-heap-block-in-IndexFetchHeapData-us.patch application/octet-stream 3.7 KB
v13-0003-Use-fake-LSNs-to-improve-nbtree-dropPin-behavior.patch application/octet-stream 15.1 KB
v13-0002-Use-GetXLogInsertEndRecPtr-in-XLogGetFakeLSN.patch application/octet-stream 3.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2026-03-12 19:45:24 Re: Adding REPACK [concurrently]
Previous Message Corey Huinker 2026-03-12 19:41:54 Re: Import Statistics in postgres_fdw before resorting to sampling.