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

From: Sami Imseih <samimseih(dot)pg(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tomas Vondra <tomas(at)vondra(dot)me>
Subject: Re: Showing "Table Block Fetches" in EXPLAIN ANALYZE for index-only scans
Date: 2026-10-15 22:04:35
Message-ID: CAN12+YKuDHUSJEApCK-Wk3fjj8aRWWCEs8BYPxxzSuHgpw9t8g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

> "Table Block Fetches" is exactly the number of times an index-only
> scan had to switch to a new heap block. I'm not fussed about the name
> we use for this, though I think that avoiding references to heap is
> desirable. This information is table AM agnostic, at least in theory.

I did not look too much into the patch details, but I do think this is a
good idea. For example, there can be a real cost difference between checking
visibility for 20 table tuples spread across 20 table blocks and checking
visibility for 20 table tuples packed onto 1 table block. So having such
additional information seems valuable. Exposing this in pg_stat_*_indexes
would also make sense.

> I lean towards not showing anything about IoS heap tuple fetches in
> EXPLAIN ANALYZE, which is how it's done in this V1. But if there's a
> consensus in favor of keeping it, I can easily produce a revision that
> counts and reports on both things.

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.

--
Sami Imseih
Amazon Web Services (AWS)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-10-15 22:08:49 Re: Parallel vacuum: avoid dangling shared memory pointers
Previous Message Baji Shaik 2026-10-15 22:00:39 Re: [PATCH] Doc fix for autovacuum_max_parallel_workers