Re: Reduce cleanup lock contention on standby replay

On Fri, Jul 10, 2026 at 6:40 PM SATYANARAYANA NARLAPURAM
<satyanarlapuram(at)gmail(dot)com> wrote:
> Both flags are set only when:
> - The index is unique (rd_index->indisunique)
> - Scan keys cover all key columns (NumScanKeys >= indnkeyatts)

I think that carrying around metadata indicating "unique scan,
guaranteed to return 0 or 1 rows under MVCC" could be useful in a few
places.

Are you careful about NULLs/IS [NOT] NULL conditions? Those aren't
guaranteed to return 0 or 1 rows with an MVCC snapshot, even with a
unique index.

> This guarantees at most one heap page visit per scan, so there is no same-page pin reuse benefit to preserve (unlike range scans where consecutive tuples often share a buffer).
> I didn't see any obvious difference in performance with this change because the materialize cost (one heap_copytuple per point lookup) is negligible compared to
> the index traversal + buffer lock cycle.

Are you familiar with the amgetbatch interface that some of us have
been working on to enable index prefetching? Tomas Vondra and I talked
about the architecture at pgConf.dev:

https://2026.pgconf.dev/session/659

That might complement work in this area. As the talk goes into, a big
emphasis of the work is to centralize knowledge of the progress of
index scans in one place (namely heapam_indexscan.c) to enable work
reordering. The table AM is at liberty to do work in whatever order is
fastest or most convenient, as long as that doesn't break the index
scan's semantics. We need this for prefetching, but it's actually a
very general strategy.

Many index scans return a range of rows whose TIDs all came from the
same index leaf page. With such an index scan, there'll only be one
call to amgetbatch. The first time amgetbatch returns it'll usually
already be clear that it's the first and last batch; this can be
determined right after the first/only amgetbatch call. You can see
everything almost immediately, or at least easily see into the near
future -- without any added overhead. This should make it possible to
intelligently decide whether to eagerly fetch and materialize tuples
in more complicated cases -- lots of relevant context is readily
available in one place.

--
Peter Geoghegan