Re: EXPLAIN omits schema? - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: EXPLAIN omits schema?
Date
Msg-id 878xanyhce.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: EXPLAIN omits schema?  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: EXPLAIN omits schema?  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: EXPLAIN omits schema?  ("Florian G. Pflug" <fgp@phlo.org>)
Re: EXPLAIN omits schema?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: EXPLAIN omits schema?  ("Nikolay Samokhvalov" <samokhvalov@gmail.com>)
List pgsql-hackers
"Joshua D. Drake" <jd@commandprompt.com> writes:

>> I agree. XML seems like a fairly natural fit for this. Just as people should
>> not try to shoehorn everything into XML, neither should they try to shoehorn
>> everything into a relational format either.
>>
>> Now all we need is an XML schema for it ;-)
>
> Well I am not a big fan of XML but it certainly seems applicable in this
> case.

I'm not a fan either so perhaps I'm biased, but this seems like a good example
of where it would be an *awful* idea.

Once you have an XML plan what can you do with it? All you can do is parse it
into constituent bits and display it. You cant do any sort of comparison
between plans, aggregate results, search for plans matching constraints, etc.

How would I, with XML output, do something like:

SELECT distinct node.relation  FROM plan_table WHERE node.expected_rows < node.actual_rows*2;

or

SELECT node.type, average(node.ms/node.cost) FROM plan_table GROUP BY node.type;

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: EXPLAIN omits schema?
Next
From: "Greg Sabino Mullane"
Date:
Subject: Re: EXPLAIN omits schema?