Re: [HACKERS] Anyone for prettyprinted EXPLAIN VERBOSE? - Mailing list pgsql-hackers

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
:basetype23 :aggtype 23 :target { VAR :varno 0 :varattno 1 :vartype 23 :vartypmod -1  :varlevelsup 0 :varnoold 1
:varoattno1} :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
:resjunkfalse } :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@debis.com (Jan Wieck) #