Re: Does anyone ever use OPTIMIZER_DEBUG? - Mailing list pgsql-hackers

From David Rowley
Subject Re: Does anyone ever use OPTIMIZER_DEBUG?
Date
Msg-id CAApHDvoMLP3ZpAE4_zivkT1GJU293BT7Yy-Kmo-kxU+Nc_-EWg@mail.gmail.com
Whole thread Raw
In response to Re: Does anyone ever use OPTIMIZER_DEBUG?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Does anyone ever use OPTIMIZER_DEBUG?
List pgsql-hackers
On Fri, 29 Sept 2023 at 10:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> We could also discuss keeping the "tracing" aspect of it, but
> replacing debug_print_rel with pprint(rel), which'd still allow
> removal of all the "DEBUG SUPPORT" stuff at the bottom of allpaths.c.
> That's pretty much all of the maintenance-requiring stuff in it.

To assist discussion, I've attached a patch for that.

I likely can't contribute much to that discussion due to being more of
an "attach a debugger" person rather than an "add printf statements"
person.

To eliminate a hurdle for anyone who wants to chip in, I've attached
the old and new debug output from the following query:

select * from pg_class where oid = 1234;

One observation is that the output is quite a bit larger with the
patched version and does not seem as useful if you wanted
OPTIMIZER_DEBUG to help you figure out why a given Path was chosen.

David

Attachment

pgsql-hackers by date:

Previous
From: Vik Fearing
Date:
Subject: Re: CHECK Constraint Deferrable
Next
From: Michael Paquier
Date:
Subject: Re: pg*.dll and *.pdb files in psqlODBC have no version numbers