Re: making EXPLAIN extensible - Mailing list pgsql-hackers

From Tom Lane
Subject Re: making EXPLAIN extensible
Date
Msg-id 2234935.1741809008@sss.pgh.pa.us
Whole thread Raw
In response to Re: making EXPLAIN extensible  (Sami Imseih <samimseih@gmail.com>)
Responses Re: making EXPLAIN extensible
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: Vacuum statistics
Next
From: Marcos Pegoraro
Date:
Subject: Missing constraint when duplicated unique index ?