Re: making EXPLAIN extensible
Alena Rybakina <a.rybakina@postgrespro.ru>
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-03T08:25:54Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_overexplain: Use PG_MODULE_MAGIC_EXT.
- 83ccc85859f3 18.0 landed
-
pg_overexplain: Call previous hooks as appropriate.
- 9f0c36aea0fb 18.0 landed
-
pg_overexplain: Additional EXPLAIN options for debugging.
- 8d5ceb113e3f 18.0 landed
-
Add an additional hook for EXPLAIN option validation.
- 50ba65e73325 18.0 landed
-
Add some new hooks so extensions can add details to EXPLAIN.
- 4fd02bf7cf94 18.0 landed
-
Make it possible for loadable modules to add EXPLAIN options.
- c65bc2e1d14a 18.0 landed
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