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-WzkBxR44xfnx6iXN5j97JTV78Z1+4MtcdKonDSD0m0-JFw@mail.gmail.com
Whole thread Raw
In response to Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)  (Matthias van de Meent <boekewurm+postgres@gmail.com>)
Responses Re: Showing primitive index scan count in EXPLAIN ANALYZE (for skip scan and SAOP scans)
List pgsql-hackers
On Tue, Aug 27, 2024 at 7:22 PM Matthias van de Meent
<boekewurm+postgres@gmail.com> wrote:
> On Tue, 27 Aug 2024 at 23:40, Peter Geoghegan <pg@bowt.ie> wrote:
> > Right, "trivial". Except in that it requires inventing a whole new
> > general purpose infrastructure.
>
> Which seems to be in the process of being invented already elsewhere.

None of this stuff about implementation details really matters if
there isn't agreement on what actual user-visible behavior we want.
We're very far from that right now.

> > Meanwhile, Tom is arguing against even
> > showing this very basic information in EXPLAIN ANALYZE.You see the
> > problem?
>
> I think Tom's main issue is additional clutter when running just plain
> `explain analyze`, and he'd probably be fine with it if this was gated
> behind e.g. VERBOSE or a new "get me the AM's view of this node"
> -flag.

I'm not at all confident that you're right about that.

> > I mean it literally works in exactly the same way! It's literally
> > indistinguishable to users, and works in a way that's consistent with
> > historical behavior/definitions.
>
> Historically, no statistics/explain-only info is stored in the
> IndexScanDesc, all data inside that struct is relevant even when
> EXPLAIN was removed from the codebase. The same is true for
> TableScanDesc

Please try to separate questions about user-visible behavior from
questions about the implementation. Here you're answering a point I'm
making about user visible behavior with a point about where the
counter goes. It's just not relevant. At all.

> Now, you want to add this metadata to the struct. I'm quite hesitant
> to start walking on such a surface, as it might just be a slippery
> slope.

I don't know why you seem to assume that it's inevitable that we'll
get a huge amount of similar EXPLAIN ANALYZE instrumentation, of which
this is just the start. It isn't. It's far from clear that even
something like my patch will get in.

> > Seems completely unrelated.
>
> I'd call "exposing function's pgstat data in explain" at least
> somewhat related to "exposing indexes' pgstat data in explain".

Not in any practical sense.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.
Next
From: David Rowley
Date:
Subject: Re: Significant Execution Time Difference Between PG13.14 and PG16.4 for Query on information_schema Tables.