(sorry for top posting - stupid apple)
So the real elephant in the room is that the existing explain code is
not really designed to be extensible, configurable, or to be printed
in different formats.
The current code is basically just gobs of text printed by different
routines all over the code base. There are no data structures which
represent what explain prints. The closest thing is the
instrumentation objects which obtain the timing and counts but not the
planner expectations or any associated data.
If we're going to support multiple output formats or options to turn
off and on sections I think we need to build a data structure
independent of the format, have code to include or exclude stats as
requested and then pass that to the requested formatter.
--
Greg
On 26 May 2009, at 18:53, Robert Haas <robertmh...@gmail.com> wrote:
On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan
<and...@dunslane.net> wrote:
Robert Haas wrote:
On the other hand, XML can be a really difficult technology to work
with because it doesn't map cleanly to the data structures that most
modern scripting languages (Perl, Python, Ruby, and probably Java
and
others) use. As a simple example, if you have a hash like { a =>
1, b
=> 2 } (using the Perl syntax) you can map it to
<hash><a>1</a><b>2</b></hash>. That's easy to generate, but the
reverse transformation is full of error-handling cases, like
<hash><a>1</a><b>2<c/></b></hash> and <hash><a>1</a><a>2</a></hash>.
I'm sure experienced XML hackers have ways to work around these
problems, but the XML libraries I've worked with basically don't
even
try to turn the thing into any sort of general-purpose data
structure.
They just let you ask questions like "What is the root element?
OK,
now what elements does it contain? OK, there's an <a> tag there,
what
does that have inside it? Any more-deeply-nested tags?". On the
other hand, JSON is explicitly designed to serialize and deserialize
data structures of this type, and it pretty much just works, even
between completely different programming languages.
Since we will be controlling the XML output, we can restrict it to
a form
that is equivalent to what JSON and similar serialisation languages
use. We
can even produce an XSD schema specifying what is allowed, if
anyone is so
minded, and a validating parser could be told to validate the XML
against
that schema. And XSLT processing is a very powerful transformation
tool. We
could even provide a stylesheet that would turn the XML into
JSON. :-)
Yeah, that's fine. I think we should target 4/1/2010 as the
submission date for that stylesheet. :-)
Anyway, I think we're getting closer to consensus here.
I think there's a good case for being able to stash the EXPLAIN
output in a
table as XML - that way we could slice and dice it several ways
without
having to rerun the EXPLAIN.
Yes, I think there is an excellent case for being able to stash any
output format into a table.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
