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-21T00:37:26Z
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.

> It sounds like we're sufficiently in agreement so I've committed the
> patch.

Thanks!

> I've rebased my pg_overexplain patch and attach that here.

I spent some time playing around with this extension, and I can
see the value.

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.

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 ..

The user can choose which information they want to see by passing
a value to an option called query_tree_show ( or a better option name)

Initially, we can only support range_table, but future enhancements
could include other parts.

Maybe a good idea, maybe not, what do you think?


Besides that, I found a few minor things:


1/ trailing whitespace

+     <literal>Subplans Needing Rewind</literal>. Integer IDs of subplans that


2/ typos
 * We don't try to print everything here. Information that would be displyed

 * to limit the display length by # of columsn or # of characters, but for



[0] https://www.postgresql.org/message-id/8e8b6f17-e1e6-4b16-84d4-37ded802c787%40gmail.com


--

Sami Imseih
Amazon Web Services (AWS)