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-Wz=ryRkm=85q-f6CBVh0vbrq1JCjwBFhzCu_enVEUDifWA@mail.gmail.com
Whole thread Raw
In response to Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Aug 27, 2024 at 3:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> TBH, I'm afraid that this patch basically is exposing numbers that
> nobody but Peter Geoghegan and maybe two or three other hackers
> will understand, and even fewer people will find useful (since the
> how-many-primitive-scans behavior is not something users have any
> control over, IIUC).

You can make about the same argument against showing "Buffers". It's
not really something that you can address directly, either. It's
helpful only in the context of a specific problem.

> I doubt that "it lines up with
> pg_stat_all_indexes.idx_scan" is enough to justify the additional
> clutter in EXPLAIN.

The scheme laid out in the patch is just a starting point for
discussion. I just think that it's particularly important that we have
this for skip scan -- that's the part that I feel strongly about.

With skip scan in place, every scan of the kind we'd currently call a
"full index scan" will be eligible to skip. Whether and to what extent
we actually skip is determined at runtime. We really need some way of
determining how much skipping has taken place. (There are many
disadvantages to having a dedicated skip scan index path, which I can
go into if you want.)

> Maybe we should be going the other direction
> and trying to make pg_stat_all_indexes count in a less detailed but
> less surprising way, ie once per indexscan plan node invocation.

Is that less surprising, though? I think that it's more surprising.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: allowing extensions to control planner behavior
Next
From: Bertrand Drouvot
Date:
Subject: Re: Add contrib/pg_logicalsnapinspect