Re: making EXPLAIN extensible

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Sami Imseih <samimseih@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-21T12:39:30Z
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.

On Thu, Mar 20, 2025 at 8:37 PM Sami Imseih <samimseih@gmail.com> wrote:
> 1/ provides a good example for future extensions on how to
> use the new hooks. it definitely would be nice to add an example
> for the hook added to check options against each other as mentioned
> by Andrei here [0] but I could not find a good reason to do so with
> pg_overexplain.

Yeah, there may be a good idea lurking somewhere here but I have not
yet come up with it.

> 2/ I agree that this is better than debug_print_plan to avoid all the
> verbosity of that output emitting at once. But maybe it will be useful
> to provide options to show other parts like the target list, quals, etc.
> I wonder if something like this will be better?
>
> 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.

Also, the reason I didn't do the quals or the target list is because
regular EXPLAIN already shows that stuff. There could possibly be some
value in trying to show things about those node trees that regular
EXPLAIN doesn't, but that quickly gets into (a) speculation about what
people actually want to see and/or (b) extremely voluminous output
which is the whole reason debug_print_plan is hard to use in the first
place.

> 1/ trailing whitespace
> 2/ typos

Acknowledged, thanks.

-- 
Robert Haas
EDB: http://www.enterprisedb.com