On Wed, 4 Jan 2023 at 16:15, Vladimir Churyukin <vladimir@churyukin.com> wrote:
> As an end user that spends a lot of time optimizing pretty complicated queries, I'd say that something like this
couldbe 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/
