Re: index prefetching

On Wed, Aug 19, 2026 at 4:00 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Attached is v33, another revision intended only to fix bit rot.

Attached is v34. My focus was on fixing regressions in the first patch
(the "Add slot-based table AM index scan interface" one), which I'm
now very close to pushing. I pushed 3 small pieces from that same
patch earlier today.

These regressions were in index-only scans, which are more sensitive
to the extra indirection added by the slot interface. We can make up
for that to some extent with the amgetbatch interface, where most
calls to table_index_getnext_slot won't actually need to call
amgetbatch. Whereas with an amgettuple index AM, all calls to
table_index_getnext_slot are passed through to amggettuple. So I had
to micro-optimize some more to compensate; I didn't want to assume
that the amgetbatch work would eventually be committed and fix these
regressions.

And so v34 makes heapam_index_getnext_slot a little bit more
complicated to deal with those problems. With index-only scans,
actually performing a heap fetch is the slow path, so we don't inline
heapam_index_heap_fetch into heapam_index_getnext_slot anymore. It's
still important that plain scans inline heapam_index_heap_fetch into
their own specialized version of heapam_index_getnext_slot (for both
the ambatch and amgettuple specializations of
heapam_index_getnext_slot).

Other changes, all of which are also in the first patch:

* v34 also simplifies fetch_tid, the interface that we use during
constraint enforcement, in _bt_check_unique and one or two other
places. We no longer use a slot there at all, restoring the Postgres
11 behavior, or close to it (prior to the initial table AM work in
Postgres 12, we just called heap_hot_search_buffer directly, which is
close to what we're done now with fetch_tid).

* We now make index_getnext_tid (the shim function that calls through
to amgettuple) into an inline function in the first commit, not just
the later amgetbatch commit.

I moved index_getnext_tid into amapi.h, which required adding 3 new
headers to amapi.h. I think that this is probably acceptable, but I
wanted to flag it as a possible concern. This is the logical place to
put index_getnext_tid, if we have to inline it -- and it seems like
that's more or less required.

* I got rid of the index-only scan + btree/name_ops memory context,
which wasn't really necessary.

--
Peter Geoghegan