Hi,
Attached patch add a new GUC parameter auto_explain.log_options that
accepts a comma-separated list of custom EXPLAIN options registered by
extensions. This allows auto_explain to pass extension specific options
(like from pg_plan_advice) when logging query plans.
Based on pg_plan_advice and pg_overexplain use of custom explain options
I see two different cases:
1. pg_plan_advice check at planner_setup_hook() if custom explain option
is enabled or not to decide if the advice should be collected.
2. Since pg_overexplain don't collect any other data (just print more
planner information) it only check at explain_per_plan_hook() if the
custom explain option is enabled or not.
So it seems to me that we have two patterns here: 1. Custom extensions
that want to include more information during planning so in this case it
should use the planner_setup_hook() and 2. which are extensions that
don't need any extra planner information and can just hook
explain_per_plan_hook().
That being said, this patch creates a new planner_setup_hook for case
1 and changes explain_ExecutorEnd() to call explain_per_plan_hook()
for case 2. Note that even for case 1, we still need to call
explain_per_plan_hook() so the extra information from the custom
explain option is included in the explain output.
Regarding the explain_per_plan_hook() call in explain_ExecutorEnd():
normally this hook is called by ExplainOnePlan() during a regular
EXPLAIN command. However, auto_explain doesn't go through
ExplainOnePlan() - it builds its own ExplainState and calls the
individual explain functions (ExplainPrintPlan, ExplainPrintTriggers,
ExplainPrintJITSummary) directly. We can't use ExplainOnePlan()
because it expects to execute the query itself, whereas auto_explain
runs after execution is already complete (inside the ExecutorEnd hook)
and already has a QueryDesc with execution results.
Since there's no existing helper function that handles just the
"output explain for an already-executed query" portion while also
calling explain_per_plan_hook(), the only option currently is to call
explain_per_plan_hook() directly. I'm wondering if we should create
such a helper function, or if there's a better approach here?
--
Matheus Alcantara
EDB: https://www.enterprisedb.com
