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

On Tue, Aug 27, 2024 at 7:22 PM Matthias van de Meent
<boekewurm+postgres(at)gmail(dot)com> wrote:
> On Tue, 27 Aug 2024 at 23:40, Peter Geoghegan <pg(at)bowt(dot)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