Re: machine-readable explain output

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: machine-readable explain output
Дата
Msg-id 4A3795C8.4000307@anarazel.de
обсуждение исходный текст
Ответ на Re: machine-readable explain output  (Greg Stark <gsstark@mit.edu>)
Ответы Re: machine-readable explain output  (Robert Haas <robertmhaas@gmail.com>)
Re: machine-readable explain output  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] backend: compare word-at-a-time in bcTruelen