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)
