Re: making EXPLAIN extensible - Mailing list pgsql-hackers

From Andrei Lepikhov
Subject Re: making EXPLAIN extensible
Date
Msg-id 41ca9655-f905-4eec-96b3-8a3fef350548@gmail.com
Whole thread Raw
In response to Re: making EXPLAIN extensible  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: making EXPLAIN extensible
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [PATCH] PGSERVICEFILE as part of a normal connection string
Next
From: Christoph Berg
Date:
Subject: Re: query_id: jumble names of temp tables for better pg_stat_statement UX