Horton

Re: making EXPLAIN extensible

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-03-21T13:02:43Z
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 →

  1. pg_overexplain: Use PG_MODULE_MAGIC_EXT.

  2. pg_overexplain: Call previous hooks as appropriate.

  3. pg_overexplain: Additional EXPLAIN options for debugging.

  4. Add an additional hook for EXPLAIN option validation.

  5. Add some new hooks so extensions can add details to EXPLAIN.

  6. Make it possible for loadable modules to add EXPLAIN options.

> > explain (query_tree_show range_table) select ..
> > explain (query_tree_show qualification) select ..
> > explain (query_tree_show target_list) select ..
>
> But why would those options be exclusive of each other? Surely you
> could want more than one of those things, which suggests that separate
> options are better.

Yeah, that's a valid point. I guess I was thinking that if we ever
decide to have
an option for every part of the query tree, we will end up with many options
(a half dozen options or so), but not being able to support
"give me these 2 parts only" is not ideal either.

> EXPLAIN doesn't, but that quickly gets into (a) speculation about what
> people actually want to see and/or

Correct. This is why these hooks are useful and people can just
write whatever is useful to them, or if there is a convincing reason,
it can be added into pg_overexplain overtime.

overall this LGTM, and I don't really have other comments.

--
Sami Imseih
Amazon Web Services (AWS)