Re: index prefetching

On Sat, Mar 21, 2026 at 7:01 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I can immediately act on most of what you've said here. I'm planning
> to commit the first patch (and maybe the hash index fake LSN patch) in
> the next couple of days, ahead of posting a new v17 of the patch set.
> You can expect any item I reply to with "fixed" or similar to be in
> that version. Other items might not be addressed in v17 -- generally
> because I require more context or feedback to act.
>
> I'm going to work through both this email and the later one from today
> before posting this v17. What I've said applies equally to both
> reviews/emails.

I committed the fake LSN hash index patch (as commit e5836f7b), as
well as the "Make IndexScanInstrumentation a pointer in executor scan
nodes" patch (as commit f026fbf0).

V17 is attached. This addresses most of your feedback, but defers
dealing with the trickier parts for now. I didn't want to delay
producing a new version that cleanly applies on top of master.
Performance validation takes at least as long as writing the code,
with these sorts of changes.

Notable things that I have *not* done just yet:

* No new heapam_index.c file in this version (though there is an indexbatch.h).

* No split of table AM revisions that pushes down VM accesses for
index-only scans into its own commit (though there are a couple of new
patches that were split from the big one to keep the size of the
commits slightly more manageable, as promised).

* No progress on splitting the batch management code currently in
heapam_handler.c into smaller, reusable/modular pieces. Pieces that
other table AMs can reuse.

* Recently, Andres asked, "Does it really make sense to not just have
2 separate loops from within heapam_batch_resolve_visibility?". That
is a question that remains unanswered, for now.

Notable changes (things that I *have* done) include:

* Cleaned up the mess of carrying around four full-length, specialized
versions of the table AM index scan slot callback. We still
specialize, but now there's only one generic
pg_attribute_always_inline function definition, which is called by all
four specializations. The compiler can create specialized versions
because the amgetbatch + index_only_scan parameters are constants
(four specializations for all four combinations of amgetbatch +
index_only_scan boolean parameters).

* Lots of renaming and polishing, along the lines requested in your
review. Basically, everything I specifically told you I would do soon
in my initial responses over the past couple of days has been
completed. A large number of small things, that aren't worth noting
individually.

--
Peter Geoghegan