Re: generic options for explain

(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 <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan
> <andrew(at)dunslane(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers