Re: [PATCH] Improve ability to display optimizer analysis using OPTIMIZER_DEBUG

Ankit Kumar Pandey <itsankitkp(at)gmail(dot)com> writes:
> As per as suggestion in the mailing list which is to replace current
> mechanism of getting optimizer log via OPTIMIZER_DEBUG macro
> to something more configurable (which doesn't require rebuilding
> postgres from source code). This patch replaces /OPTIMIZER_DEBUG
> by introducing a//GUC /show_optimizer_log /which can be configured on
> and off to//display (or hide)//previously generated log from stdout to
> postmaster's log.

The problem with OPTIMIZER_DEBUG is that it's useless. I've
been hacking on the PG planner for well more than twenty years,
and I do not think I've ever made any use of that code ---
certainly not since the turn of the century or so.
Making it GUC-accessible isn't going to make it more useful.

There certainly could be value in having some better trace
of what the planner is doing, but I honestly don't have much
of an idea of what that would look like. debug_print_rel
isn't that, however, because it won't show you anything about
paths that were considered and immediately rejected by
add_path (or never got to add_path at all, because of the
approximate-initial-cost filters in joinpath.c). We've
sometimes speculated about logging every path submitted to
add_path, but that would likely be too verbose to be very
helpful.

Also, because OPTIMIZER_DEBUG is such a backwater, it's
never gotten much polishing for usability. There are large
gaps in what it can deal with (print_expr is pretty much
a joke for example), yet also lots of redundancy in the
output ... and dumping stuff to stdout isn't terribly helpful
to the average user in the first place. These days people
would probably also wish that the output could be machine-
readable in some way (JSON-formatted, perhaps).

So I think this whole area would need some pretty serious
rethinking and attention to detail before we should consider
claiming that it's a useful feature.

regards, tom lane