Re: making EXPLAIN extensible

On 4/3/2025 22:23, Robert Haas wrote:
> On Tue, Mar 4, 2025 at 1:53 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>> I don't expect there to be zillions of extensions that only add new and
>> exciting explain options. Instead, it seems more likely that all
>> TableAM and CustomScan extensions will have 1-3 new explain options,
>> and that some of those might collide. For example, several may have a
>> EXPLAIN(PUSHDOWN) option that explains what work is being pushed down
>> into the TableAM/CustomScan.
>>
>> In that case it's not even clear to me that a collision is a problem.
>> Would you really only want pushdown information from extension A, and
>> be upset that it also emits pushdown information from extension B?
>> Maybe we should just allow multiple extensions to use the same option
>> name?
> ...
> Actually, I don't think custom scans or table AMs are the design
> center for this feature. Keep in mind that, for a custom scan, we
> already have ExplainCustomScan as part of CustomScanState->methods. We
> don't currently have anything similar for table AMs, and you could
> work around that with these hooks, by checking every node to see
> whether it's a scan node and if so whether it scans a relation that
> matches your table AM, but it would probably be better to have a
> method for it, similar to what we have for CustomScan, if this is
> something people want to do. It would be more efficient and require
> less code.
+1. In my experience, ExplainCustomScan has always been enough for the
CustomScan node.
As for extensions collision - for now, it would be better to treat
extensions as independent actors, suggesting that the developer,
designing a software solution based on an extensions' constellation,
will arrange their behaviour during development.
For instance, if your library exports a function or variable, adding a
prefix is essential to prevent overlapping functions when another
library is loaded.
I recall that Yurii Rashkovskii is a proponent of using multiple
extensions within a single installation. Perhaps he has insights on this
topic?

--
regards, Andrei Lepikhov