Gregory Stark wrote:
> "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;
I believe that XQuery actually supports such queries. So if postgres
supported XQuery (or does it already? I honestly don't know), writing
such a query wouldn't be that hard I think. The execution probably
won't be super-efficient, but for query plans that seems OK.
greetings, Florian Pflug
