Horton

Re: making EXPLAIN extensible

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-18T18:40:19Z
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.

Robert Haas <robertmhaas@gmail.com> writes:
> If you mean just after, that would amount to deciding that information
> coming from extensions goes before information from core rather than
> after. I thought about that and it's defensible, but in the end I
> thought it made more sense for core info to come first. We could
> bikeshed this endlessly, but there's no single choice that's going to
> make everybody 100% happy, and adding a whole bunch of extra hooks to
> cater to various preferences about exactly how the output should look
> does not seem worth it to me.

FWIW, I am fairly strongly against that.  Every extension author is
going to feel that their information is so important it should come
first.  Other people might have a different opinion about that, and
in any case they can't all be first.

There's certainly room for bikeshedding here, but I think it'd be good
to get some actual experience before redesigning what you've done.

			regards, tom lane