Re: [HACKERS] Anyone for prettyprinted EXPLAIN VERBOSE?

Bruce Momjian wrote:

> I remember Jan saying he liked the compressed one.

Change it if you want to.

The reason why I prefer the nodeToString() format is bacause
(even if it might look like garbage to someone) for me it's
the only way to LOOK if the right node went from the parsed
state into the rewritten state. Or if an OLD/NEW got
rewritten correctly into the scan relation's/TLE's one.
That's impossible if having the prettyprint only, because for
non-trivial trees the output occurs hundreds (if not
thousands) of lines later, especially if multi-action rules
or subselects get involved. Not to tell about recursive and
conditional rules getting applied (note that conditional
instead rules put out two trees, one with the negated rule
qual and the original action, one with the original rules
qual and action). To compare in such a case, if anything was
done well, really requires to look at rewriter input AND
output.

I have a scrollback buffer of 2000 lines on my XTerm icon,
and it already happened that I wasn't able to scroll back to
the wanted location WHILE USING COMPRESSED FORMAT ONLY!

But if we get our hands on the parsetree overhaul, I can
insert my own "printf(...nodeToString())" statements into the
places, where I really need to look at. That's usually
another place, than these messages are coming from.

I'm only in doubt about if anyone at all DOES use the pretty
printed version for anything. I assume I'm not too bad in
reading printed parsetrees, but whenever the pretty printed
tree exceeds some hundreds of lines, I'm totally lost and am
unable to find the location I'm looking for (what I easily do
when looking at the compressed format). I allways wondered
why the pretty print was implemented at all.

Who really USES the explanative format to debug things on
non-trivial queries?

Since Tom is asking, I assume at least he's the one who does.
But then again, he must be able to see his target station
expressed in some Expr-, Oper- and Func- nodes while pushing
the buttons to get an underground-ticket. So who else does
like the pretty printed version better for non-esthetical
reasons?

Jan

>
>
> > When you do an EXPLAIN VERBOSE, two different representations of the
> > query plan are produced. The client sees something like this:
> >
> > regression=> explain verbose select sum(f1) from int4_tbl;
> > NOTICE: QUERY DUMP:
> >
> > { AGG :cost 1.165 :size 5 :width 4 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname "sum" :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { AGGREG :aggname sum :basetype 23 :aggtype 23 :target { VAR :varno 0 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1} :usenulls false }}) :qpqual <> :lefttree { SEQSCAN :cost 1.165 :size 5 :width 4 :state <> :qptargetlist ({ TARGETENTRY :resdom { RESDOM :resno 1 :restype 23 :restypmod -1 :resname "<>" :reskey 0 :reskeyop 0 :ressortgroupref 0 :resjunk false } :expr { VAR :varno 1 :varattno 1 :vartype 23 :vartypmod -1 :varlevelsup 0 :varnoold 1 :varoattno 1}}) :qpqual <> :lefttree <> :righttree <> :extprm () :locprm () :initplan <> :nprm 0 :scanrelid 1 } :righttree <> :extprm () :locprm () :initplan <> :nprm 0 }
> >
> > but in the postmaster log we format it like this:
> >
> > NOTICE: QUERY PLAN:
> >
> > Aggregate (cost=1.16 rows=5 width=4)
> > -> Seq Scan on int4_tbl (cost=1.16 rows=5 width=4)
> >
> > { AGG
> > :cost 1.165
> > :size 5
> > :width 4
> > :state <>
> > :qptargetlist (
> > { TARGETENTRY
> > :resdom
> > { RESDOM
> > :resno 1
> >
> > [...]
> >
> > :righttree <>
> > :extprm ()
> >
> > :locprm ()
> >
> > :initplan <>
> > :nprm 0
> > }
> >
> > Does anyone think that the first form has any conceivable use? I would
> > like to get rid of it and deliver the prettyprinted format to both log
> > and client. I think it may have been done this way because old versions
> > of the backend didn't cope very gracefully with sending long NOTICE
> > messages to the client, but that constraint is history...

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #