Horton

Re: making EXPLAIN extensible

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

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2025-03-12T19:50:08Z
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.

Sami Imseih <samimseih@gmail.com> writes:
> 1/ As you can see form the output above, I used explain_per_node_hook
> to append a "Plan Node ID" to the explain output. I really don't like having it
> there, and prefer that it gets added to the top line of the node.

> i.e.
>    ->  Foreign Scan on t_r1  (cost=100.00..673.20 rows=2560 width=8) (node_id=1)
>    ->  Materialize  (cost=100.00..686.00 rows=2560 width=8) (node_id=2)
>          ->  Foreign Scan on t1_r1  (cost=100.00..673.20 rows=2560
> width=8) (node_id=3)

> Can we add a hook at that point [1] which will allow an extension to modify
> the first line of a node? I think this is not just useful for my case, but also
> for other use-cases in which some high level node details could be placed.
> what do you think?

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.  Plus, this doesn't consider what to do in non-text
output formats.  ISTM you should be good with adding a new
"Plan Node ID" property to each node.  No, you don't get to put it
first.  Too bad.  (If we did try to cater to that, what shall we do
with multiple extensions that all think they should be first?)

The validation point is an interesting one.  I agree that we don't
want the behavior to depend on the order in which options are
written.

			regards, tom lane