Re: generic options for explain - Mailing list pgsql-hackers

From Robert Haas
Subject Re: generic options for explain
Date
Msg-id 603c8f070905250414q63ea57f2g9fb4659b8cd59cbd@mail.gmail.com
Whole thread Raw
In response to Re: generic options for explain  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: generic options for explain  (Joshua Tolley <eggyknap@gmail.com>)
Re: generic options for explain  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, May 25, 2009 at 6:24 AM, Dimitri Fontaine
<dfontaine@hi-media.com> wrote:
> I think the summary here is to say that we want two modes of operations:
>  - the current one, which continues to get refinements
>
>  - a new one conveying all possible information in machine readable
>   formats, possibly with some tools to handle it easily: XML output and
>   maybe XSLT stylesheets

I don't agree with that summary.  Many people who responded to this
thread were fine with the idea of some sort of options syntax, but we
had at least four different proposals for how to implement it:

Robert Haas: EXPLAIN (foo 'bar', baz 'bletch', ...) query
Pavel Stehule: explain_query(query, options...) [exact format of
options not specified]
Andrew Dunstan:  SET explain_format = 'foo, baz'; EXPLAIN query
Josh Tolley: EXPLAIN (foo, baz, ...) query [also suggested by me as an
idea I rejected]

Tom Lane was the only person to suggest that we only ever need one
more option to EXPLAIN and that it should be called XML.  Even though
I prefer my format to the other options suggested (which I would
probably rank in order of descending preference Josh-Andrew-Pavel), I
am actually someone encouraged that we might have some kind of fragile
consensus that an extensible options syntax is useful (a point that
Andres Freund and Greg Smith also seemed to agree with).

>> Anyway, I'm suprised by the reaction to this patch, but I'll drop it.
>> I would like to make the EXPLAIN syntax more powerful for command-line
>> use, and I'd implement XML format and JSON along the way just for
>> completeness.  But I don't have much interest in creating an XML
>> output format that is the ONLY way of getting more information,
>> because I'm a command-line user and it does me no good at all.  :-(
>
> That's only because you seem to be thinking that having core PostgreSQL
> do the first half of the work means you as a user will have to do the
> second part. I assume pgadmin and phppgadmin developers will offer their
> users some graphical approach to the output reading, with dynamic
> filtering, eg.
>
> I don't see anything stopping you to provide a simple way to have the
> same facility into psql. You can already have the query output filtered
> by any script you want this way:
>  =# \o |my_presentation_script <style name> | <stylesheet full path>
>  =# explain XML ...
>  =# \o

This is all much more complicated than what I proposed, and I fail to
see what it buys us.  I'd say that you're just reinforcing the point I
made upthread, which is that insisting that XML is the only way to get
more detailed information will just create a cottage industry of
beating that XML output format into submission.

...Robert


pgsql-hackers by date:

Previous
From: tomas@tuxteam.de
Date:
Subject: Re: generic options for explain
Next
From: Pavel Stehule
Date:
Subject: forward declaration in c