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