Re: machine-readable explain output - Mailing list pgsql-hackers

From Andres Freund
Subject Re: machine-readable explain output
Date
Msg-id 4A3795C8.4000307@anarazel.de
Whole thread Raw
In response to Re: machine-readable explain output  (Greg Stark <gsstark@mit.edu>)
Responses Re: machine-readable explain output  (Robert Haas <robertmhaas@gmail.com>)
Re: machine-readable explain output  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
On 06/16/2009 02:14 PM, Greg Stark wrote:
> On Tue, Jun 16, 2009 at 12:19 PM, Andres Freund<andres@anarazel.de>  wrote:
>> <Startup-Cost>1710.98</Startup-Cost>
>> <Total-Cost>1710.98</Total-Cost>
>> <Plan-Rows>72398</Plan-Rows>
>> <Plan-Width>4</Plan-Width>
>> <Actual-Startup-Time>136.595</Actual-Startup-Time>
>> <Actual-Total-Time>136.595</Actual-Total-Time>
>> <Actual-Rows>72398</Actual-Rows>
>> <Actual-Loops>1</Actual-Loops>
>
> XML's not really my thing currently but it sure seems strange to me to
> have *everything* be a separate tag like this. Doesn't XML do
> attributes too? I would have thought to use child tags like this only
> for things that have some further structure.

> I would have expected something like:
>
> <join
>      <scan type=sequential source="foo.bar">
>          <estimates cost-startup=nnn cost-total=nnn rows=nnn width=nnn></>
>          <actual time-startup=nnn time-total=nnnn rows=nnn loops=nnn></>
>      </scan>
>      <scan type=function source="foo.bar($1)">
>          <parameters>
>               <parameter name="$1" expression="...."></>
>           </parameters>
>       </scan>
> </join>
>
>
> This would allow something like a graphical explain plan to still make
> sense of a plan even if it finds a node it doesn't recognize. It would
> still know generally what to do with a "scan" node or a "join" node
> even if it is a new type of scan or join.
While that also looks sensible the more structured variant makes it 
easier to integrate additional stats which may not easily be pressed in 
the 'attribute' format. As a fastly contrived example you could have io 
statistics over time like:
<iostat>   <stat time="10" name=pagefault>...</stat>   <stat time="20" name=pagefault>...</stat>   <stat time="30"
name=pagefault>...</stat>
</iostat>

Something like that would be harder with your variant.

Structuring it in tags like suggested above:
<Plan-Estimates>    <Startup-Cost>...</Startup-Cost>    ...
</Plan-Estimates>
<Execution-Cost>    <Startup-Cost>...</Startup-Cost>    ...
</Execution-Cost>

Enables displaying unknown 'scalar' values just like your variant and 
also allows more structured values.

It would be interesting to get somebody having used the old explain in 
an automated fashion into this discussion...

Andres


pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Next
From: Robert Haas
Date:
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen