Horton

Re: making EXPLAIN extensible

Andrei Lepikhov <lepihov@gmail.com>

View thread
From: Andrei Lepikhov <lepihov@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-04T13:56:40Z
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 28/2/2025 20:26, Robert Haas wrote:
> So here are some patches.
Yes, this is a big pain for extension developers. As I remember, it was 
discussed multiple times in the hackers' mailing list.
Because there is no explain node hook, I use a patch in almost each of 
my extensions: I write optimisation helpers, and it is necessary to show 
which node was influenced and how. I guess pg_hint_plan will also profit 
from this extra extensibility.

Passing through the patches, I would say that changing the order of 0001 
and 0002 would make them more independent.
Also, I'm ok with the floating order of extension messages in the 
explain output. We get used to living with dependencies on extension 
load order (pg_stat_statements quite annoyingly impacts queryid, for 
example), and this issue should be solved generally, in my opinion.
I support the way where extensions are allowed to print info but not 
restructure or remove something.
Wait for the commit!

-- 
regards, Andrei Lepikhov