Re: generic options for explain

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

In response to

Responses

Browse pgsql-hackers by date

  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