Re: making EXPLAIN extensible

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Sami Imseih <samimseih@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Thom Brown <thom@linux.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-03-22T08:46:19Z
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 3/21/25 20:54, Robert Haas wrote:
> On Fri, Mar 21, 2025 at 2:37 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Here's v9, which also adds 'SET debug_parallel_query = off' to the
> pg_overexplain tests, per CI, because the test results are not (and
> cannot realistically be made) stable under under that option.
I skimmed through the code and tested how it works.
It looks good and has no apparent architectural dependencies.
But I haven't scrutinised it line-by-line and do not intend to do so.
I wanna say I hate the design of this module. Having a strong necessity 
for extra explain tools (in the daily routine, all I have is the only 
single explain analyse verbose output to find out planner/executor bug, 
reproduce it and make a patch), I don't see a single case when I would 
use this module. It adds a burden to fix its output on a node change 
(you don't care, but it adds work to Postgres fork maintainers, too, for 
nothing). Also, it breaks my understanding of the principles of the 
Postgres code design - to start the discussion on how to show more, we 
need only the bare minimum of code and output lines.
In my opinion, it should show as few parameters as possible to 
demonstrate principles and test the code on a single planner node. It 
only deserves src/test/modules because it is not helpful for a broad 
audience.

-- 
regards, Andrei Lepikhov