Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)
Date
Msg-id CAH2-Wzm0Ady3j6-ipPWRzNow84-Xm0Mgo92FPMHmq3DtZMJGsw@mail.gmail.com
Whole thread Raw
In response to Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Jul 23, 2025 at 1:50 PM Andres Freund <andres@anarazel.de> wrote:
> 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?

There was no very good reason behind my choice to do things that way.
I wanted to minimize the amount of churn in files like
nodeIndexScan.c. It was almost an arbitrary choice.

> 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.

Offhand, I'd say that it would almost certainly be okay to switch over
to using dynamic allocation for IndexScanInstrumentation, instead of
storing it inline in IndexScanState/IndexOnlyScanState. That way you
could add many more fields to IndexScanInstrumentation, without that
creating any memory bloat problems in the common case where the scan
isn't running in an EXPLAIN ANALYZE.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Making type Datum be 8 bytes everywhere
Next
From: Tom Lane
Date:
Subject: Re: Making type Datum be 8 bytes everywhere