Hi Peter, On Fri, Jul 10, 2026 at 4:21 PM Peter Geoghegan <[email protected]> wrote:
> On Fri, Jul 10, 2026 at 6:40 PM SATYANARAYANA NARLAPURAM > <[email protected]> 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
