Re: making EXPLAIN extensible - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: making EXPLAIN extensible
Date
Msg-id ea8572f131671f24ca36c2e0e4d5d48f60927a72.camel@j-davis.com
Whole thread Raw
In response to Re: making EXPLAIN extensible  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making EXPLAIN extensible
List pgsql-hackers
It would be good to clarify whether this is for (a) experimenting with
explain options that might be useful in core some day; or (b) special
developer-only options that would never be useful in core; or (c)
production-grade explain options specific to an extension.

On Tue, 2025-03-04 at 16:23 -0500, Robert Haas wrote:
> Where I see this being more useful is for people who want to display
> additional information for plan nodes that they did not implement.
> For
> example, my EXPLAIN (RANGE_TABLE) option dumps every
> range-table-related fact it can find in the Plan tree.

That sounds like (b) or maybe (a).

But the first motivation you listed when introducing the patch was: "It
wouldn't make sense for core to have an EXPLAIN option whose whole
purpose is to cater to the needs of some extension, so that made me
think of providing some extensibility infrastructure."

which sounds like (c).

And if (c) is part of the intended use, but not CustomScan or TableAM,
then what kind of extensions would need extension-specific explain
options?

I am not trying to push the patch in any particular direction. On the
contrary, I'd just like to know the scope of the feature so that I can
stop accidentally pushing it in some direction by asking questions
about out-of-scope use cases.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Should we add debug_parallel_query=regress to CI?
Next
From: Robert Haas
Date:
Subject: Re: making EXPLAIN extensible