Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> 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.
Honestly, I had never even considered doing such a thing. I would just
like a nice way to parse explain output :)
Joshua D. Drake
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;
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
