Re: making EXPLAIN extensible - Mailing list pgsql-hackers

From Alena Rybakina
Subject Re: making EXPLAIN extensible
Date
Msg-id c8ff4f14-e3e3-470a-a31c-7811fec2727b@postgrespro.ru
Whole thread Raw
In response to making EXPLAIN extensible  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi! I agree with your idea to expand the explain.

On 28.02.2025 22:26, Robert Haas wrote:
0002 provides hooks that you can use to make your new EXPLAIN options
actually do something. In particular, this adds a new hook that is
called once per PlanState node, and a new nook that is called once per
PlannedStmt. Each is called at an appropriate point for you to tack on
more output after what EXPLAIN would already produce.

0003 adds a new contrib module called pg_overexplain, which adds
EXPLAIN (DEBUG) and EXPLAIN (RANGE_TABLE). I actually think this is
quite useful for planner hacking, and maybe a few more options would
be, too. Right now, if you want to see stuff that EXPLAIN doesn't
clearly show, you have to use SET debug_print_plan = true, and that
output is so verbose that finding the parts you actually want to see
is quite difficult. Assuming it gives you the details you need,
EXPLAIN (RANGE_TABLE) looks way, way better to me, and if we end up
committing these patches I anticipate using this semi-regularly.


There are plenty of debatable things in this patch set, and I mention
some of them in the commit messages. The hook design in 0002 is a bit
simplistic and could be made more complex; there's lots of stuff that
could be added to or removed from 0003, much of which comes down to
what somebody hacking on the planner would actually want to see. I'm
happy to bikeshed all of that stuff; this is all quite preliminary and
I'm not committed to the details. The only thing that would disappoint
me is if somebody said "this whole idea of making EXPLAIN extensible
is stupid and pointless and we shouldn't ever do it." I will argue
against that vociferously. I think even what I have here is enough to
disprove that hypothesis, but I have a bunch of ideas about how to do
more. Some of those require additional infrastructure and are best
proposed with that other infrastructure; some can be done with just
this, but I ran out of time to code up examples so here is what I have
got so far.

Hope you like it, sorry if you don't.

while writing the AQO extension [0] we were just adding a hook (we called it ExplainOnePlan_hook) similar to this one to add a description for the node used in the plan, in particular its identifier and the cardinality that is used during query planning. We also added a guc that allows user to disable this debug information, since it can only be useful when analyzing a problematic query, but not all the time. Therefore, I think this work is necessary and needed to provide the necessary output of additional information about the plan, which may be necessary for extensions like this.

[0] https://github.com/postgrespro/aqo

-- 
Regards,
Alena Rybakina
Postgres Professional

pgsql-hackers by date:

Previous
From: Andrei Lepikhov
Date:
Subject: Re: MergeJoin beats HashJoin in the case of multiple hash clauses
Next
From: jian he
Date:
Subject: Re: bug when apply fast default mechanism for adding new column over domain with default value