Re: Easily reading debug_print_plan - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Easily reading debug_print_plan
Date
Msg-id 11290.1384958186@sss.pgh.pa.us
Whole thread Raw
In response to Easily reading debug_print_plan  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Easily reading debug_print_plan  (Robert Haas <robertmhaas@gmail.com>)
Re: Easily reading debug_print_plan  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Craig Ringer <craig@2ndquadrant.com> writes:
> I'm spending a lot of time staring at parse and plan trees at the
> moment, and I'm finding reading them rather cumbersome.

Is there a particular reason you're doing that rather than looking at
EXPLAIN output?  Only the latter is meant to be at all user-friendly.

> For those of you who do this a lot, do you use any sort of tooling to
> help you out? Just being able to collapse and expand subtrees would be a
> lifesaver.

vim was mentioned --- I prefer emacs, which can also find the matching
brace pretty easily.

> If it's a hassle for others too, how would you feel about using json as
> an output format in future releases? It'd be pretty simple to retrofit
> by the looks, though updating the regression tests would be a PITA. My
> main concern would be effects on back-patching.

The internal trees appear nowhere in the regression test outputs AFAIK.

> The same representation is used for storing rules. So it can't be
> changed for BC reasons and compactness/performance.

We could in principle change to a different text representation for
stored rules.  Compactness would be an issue if it were materially
bigger than the existing formatting, but offhand it seems like JSON
is morally equivalent to what we do now, no?

If you think this is worthwhile, you might care to take a look at
outfuncs.c/readfuncs.c and figure out what it'd take to switch to
json-compatible formatting.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: Followup patches for ECPG readahead, was: Re: ECPG FETCH readahead
Next
From: Andres Freund
Date:
Subject: Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1