On Thu, Oct 15, 2026 at 6:04 PM Sami Imseih <[email protected]> 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
