Re: generic options for explain
От | Robert Haas |
---|---|
Тема | Re: generic options for explain |
Дата | |
Msg-id | 603c8f070905250414q63ea57f2g9fb4659b8cd59cbd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: generic options for explain (Dimitri Fontaine <dfontaine@hi-media.com>) |
Ответы |
Re: generic options for explain
(Joshua Tolley <eggyknap@gmail.com>)
Re: generic options for explain (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: