Re: Showing "Table Block Fetches" in EXPLAIN ANALYZE for index-only scans

On Thu, Oct 15, 2026 at 6:04 PM Sami Imseih <samimseih(dot)pg(at)gmail(dot)com> wrote:
> I think we should keep the equivalent of "Heap Fetches", although I do
> think the name itself has always seemed too vague. It is easy to read it
> as blocks, or as rows returned, when it is really counting table tuple
> visibility checks. "Table Tuple Fetches" would be clear along with the one
> you're proposing.

+1 to both: count blocks as Peter's v1 does, and keep a tuple count
beside it.

One case for keeping the tuple count that doesn't depend on heap. In
heap with selective index updates (CF 6968), an index-only scan whose
page isn't all-visible fetches the row and may then drop the entry,
because the HOT chain it walked changed a column that index covers. The
two counters together show that. Many tuple fetches on few blocks, with
fewer rows returned than entries fetched, means stale entries that
VACUUM hasn't reached. Neither number alone says that.

A question about where this goes next, since ddce1da5 put these counters
in the table AM. The in-place AM I'm working on (FLUX, CF 7389)
disables index-only scans because delete-marked entries can carry stale
keys. Its costs are on plain Index Scans: rows rebuilt from UNDO, and
entries rejected after the fetch. Would you be against the same
IndexScanInstrumentation fields being shown on plain Index Scan nodes
too, filled by the table AM, if a later patch wanted that? I'm not
asking for it in this one.

best.

-greg