Horton

Re: making EXPLAIN extensible

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>
Cc: Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Yurii Rashkovskii <yrashk@omnigres.com>
Date: 2025-03-05T10:00:06Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pg_overexplain: Use PG_MODULE_MAGIC_EXT.

  2. pg_overexplain: Call previous hooks as appropriate.

  3. pg_overexplain: Additional EXPLAIN options for debugging.

  4. Add an additional hook for EXPLAIN option validation.

  5. Add some new hooks so extensions can add details to EXPLAIN.

  6. Make it possible for loadable modules to add EXPLAIN options.

On 4/3/2025 22:23, Robert Haas wrote:
> On Tue, Mar 4, 2025 at 1:53 PM Jeff Davis <pgsql@j-davis.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