From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dave Page <dpage(at)pgadmin(dot)org> |
Subject: | Re: generic options for explain |
Date: | 2009-05-26 13:52:36 |
Message-ID: | 4A1BF424.4040908@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Now there is a third set of desires having to do with being able to do
> simple SQL-based analysis of EXPLAIN output. That's the piece I think
> we don't have a good handle on. In particular, it's not clear whether
> a SQL-friendly output format can be the same as either of the other
> two. (I don't personally find this goal very compelling --- there is
> no natural law saying that SQL is a good tool for analyzing EXPLAIN
> output --- but I'm willing to look at it to see if it's feasible.)
>
>
>
In libxml-enabled builds at least, this could presumably be done fairly
easily via the XML functions, especially if we get XSLT processing into
the core XML functionality as I hope we can do this release. In fact,
the ability to leverage existing XML functionality to munge the output
is the thing that swings me in favor of XML as the machine readable
output format instead of JSON, since we don't have and aren't terribly
likely to get an inbuilt JSON parser. It means we wouldn't need some
external tool at all.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-05-26 13:55:55 | Re: generic options for explain |
Previous Message | Tom Lane | 2009-05-26 13:47:44 | Re: problem with plural-forms |