On Mon, Aug 25, 2025 at 3:46 PM Robert Haas <robertmhaas@gmail.com> wrote:
> 0005 is a demo, not for commit, just to show how these pieces fit
> together. It uses the hooks from 0001 to count the number of times
> set_join_pathlist_hook is called and the number of those that are for
> distinct joinrels. Then it uses planner_shutdown_hook to propagate
> that into the PlannedStmt, and makes EXPLAIN (DEBUG) print those
> values out. I think there are far more interesting bits of information
> that could be preserved and propagated using this infrastructure,
> though some of them probably also require other changes to make it all
> work. But this is a simple example to show that the concept is valid
> even without anything else.
While mulling this over, I realized that this only works if you don't
mind propagating information into the final plan regardless without
knowing whether or not EXPLAIN was actually used. That's pretty sad,
because whatever you want to propagate into the final plan has to be a
node tree, and you probably had the data in some more digestible form
during planning, and so now you have to go do a whole bunch of work to
convert it into a format that the node infrastructure can digest and
most of the time that's going to be useless. Now, as far as I can see
that's not really an argument against anything in the patch set, which
I'm still hoping someone will review, but it's probably a good
argument that something more is needed.
The simplest idea that comes to mind for me is to make pg_plan_query()
take an ExplainState * argument and pass it through to planner().
Non-EXPLAIN callers can pass NULL, and planner extensions can get
control in via planner_hook() and GetExplainExtensionState() on any
provided ExplainState to figure out what they want to do. However, a
hole in this plan is the case where we call ExplainExecuteQuery(). In
that case, and I believe only that case, pg_plan_query() is not
called; instead, we fetch a plan from the plan cache, and that may be
an already-existing plan, in which case there's no option to
retroactively go back in time and save more or different information.
I don't really know what to do about that. We could ignore that case
and let extensions that work in this way document this as a caveat, or
we could try to force GetCachedPlan() to re-plan if an ExplainState is
provided, or maybe there's some other option.
--
Robert Haas
EDB: http://www.enterprisedb.com
