Re: making EXPLAIN extensible

On Sat, Mar 22, 2025 at 4:46 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
> 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.

Gee, thanks for the ringing endorsement. :-)

I think *I* will use it pretty regularly; I already have. In my
experience, using debug_query_plan for this sort of thing sucks quite
a lot. Finding the information you need in the output takes a long
time because the output is quite long. This is much more
understandable, at least for me. I agree with you that a trivial test
module could demonstrate that the hook works, but a trivial example
would not demonstrate that the hook can be used to do something
actually useful. It sounds like what I've written also fails the
"actually useful" test for you, but it doesn't for me. I'm not going
to insist on shipping this if I'm the ONLY one who would ever get any
use out of it, but I doubt that's the case.

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