Re: generic options for explain - Mailing list pgsql-hackers

(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@gmail.com> wrote:

> On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan  
> <andrew@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