Horton

Re: making EXPLAIN extensible

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Sami Imseih <samimseih@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-03-17T13:10:23Z
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 3/12/25 20:58, Sami Imseih wrote:
>> I think this is a seriously bad idea.  The first line is already
>> overloaded; we don't need several different extensions adding more
>> stuff to it.
> 
> Fair enough.
> 
>> Plus, this doesn't consider what to do in non-text
>> output formats.
> 
> the hook will be a no-op for non-text formats, which is not
> desirable behavior. I get that also.
> 
> I have no strong feelings for this, but wanted to see what
> others think.
I'm against it. For me, the best model there is to allow extensions to 
add something and nothing more. If it wants to change the core explain 
code - use ExplainOneQuery_hook instead.
The reason here is to reduce possible competition among extensions.

I already have troubles with conflict on queryid modifications and 
potential conflict in the planner_hook - if someone invents another 
extension that will provide a plan tree. So, it would be better to 
reduce conflicts whenever possible.

-- 
regards, Andrei Lepikhov