Horton

Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-07-23T17:50:50Z
Lists: pgsql-hackers 
Hi,

On 2025-03-08 11:47:25 -0500, Peter Geoghegan wrote:
> My current plan is to commit this on Tuesday or Wednesday, barring any
> objections.

A minor question about this patch: Was there a particular reason it added the
index specific instrumentation information inline in IndexScanState etc?  Of
course the amount of memory right now is rather trivial, so that is not an
issue memory usage wise. Is that the reason?

The background for my question is that I was looking at what it would take to
track the index and table buffer usage separately for
IndexScanState/IndexOnlyScanState and IndexScanInstrumentation seems to be
pre-destined for that information. But it seems a a bit too much memory to
just keep a BufferUsage around even when analyze isn't used.


Greetings,

Andres Freund


PS: Another thing that I think we ought to track is the number of fetches from
the table that missed, but that's not really related to my question here or
this thread...

Commits

  1. Show index search count in EXPLAIN ANALYZE, take 2.

  2. Show index search count in EXPLAIN ANALYZE.

  3. Allow usage of match_orclause_to_indexcol() for joins

  4. Fix nbtree pgstats accounting with parallel scans.

  5. Enhance nbtree ScalarArrayOp execution.

  6. Fix EXPLAIN ANALYZE of hash join when the leader doesn't participate.