| From: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> |
|---|---|
| To: | <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Add custom EXPLAIN options support to auto_explain |
| Date: | 2026-03-26 19:18:26 |
| Message-ID: | DHCYFNC0WIF4.3T1M8AUK0DG7T@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Add-custom-EXPLAIN-options-support-to-auto_explai.patch | text/plain | 9.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-03-26 19:30:37 | Re: Rename LWLockNewTrancheId() parameter from "name" to "tranche_name" |
| Previous Message | Tom Lane | 2026-03-26 19:17:39 | Re: Document How Commit Handles Aborted Transactions |