On Wed, 4 Jan 2023 at 16:15, Vladimir Churyukin <vladi...@churyukin.com> wrote: > As an end user that spends a lot of time optimizing pretty complicated > queries, I'd say that something like this could be useful.
I think we really need to at least see that it *is* useful, not that it *could be* useful. For example, as an end user, you might not find it great that the output is sent to stdout rather than to the window that you execute the query in. >From what I can see here, the motivation to make this a useful feature is backwards from what is normal. I think if you're keen to see a feature that allows you better visibility into rejected paths then you need to prove this is it rather than speculating that it might be useful. There was a bit of work being done in [1] with the end goal of having the ability for add_path to call a hook function before it outright rejects a path. Maybe that would be a better place to put this and then write some contrib module that provides some extended output in EXPLAIN. That might require some additional fields so that we could carry forward additional information that we'd like to show in EXPLAIN. I imagine it's not ok just to start writing result lines in the planner. The EXPLAIN format must be considered too and explain.c seems like the place that should be done. add_path might need to become a bit more verbose about the reason it rejected a certain path for this to be useful. David [1] https://commitfest.postgresql.org/39/3599/
