Re: Reduce cleanup lock contention on standby replay

Hi Peter,

On Fri, Jul 10, 2026 at 4:21 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> 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.

You are right, this needs to be handled better. Let me review and fix.

>
>
> > 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.

Thanks, I will go through this.

Thanks,
Satya