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

David Fetter wrote:
> On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
>   
>> Robert Haas <robertmhaas@gmail.com> writes:
>>     
>>> This is all much more complicated than what I proposed, and I fail
>>> to see what it buys us.  I'd say that you're just reinforcing the
>>> point I made upthread, which is that insisting that XML is the
>>> only way to get more detailed information will just create a
>>> cottage industry of beating that XML output format into
>>> submission.
>>>       
>> The impression I have is that (to misquote Churchill) XML is the
>> worst option available, except for all the others.  We need
>> something that can represent a fairly complex data structure, easily
>> supports addition or removal of particular fields in the structure
>> (including fields not foreseen in the original design), is not hard
>> for programs to parse, and is widely supported --- ie, "not hard"
>> includes "you don't have to write your own parser, in most
>> languages".  How many realistic alternatives are there?
>>     
>
> JSON for one, and it's *much* lighter in just about every way.
>
> Cheers,
> David.
>   

For what it's worth, if this revised output form is destined for 
consumption by a machine, it really doesn't matter what protocol is used 
and how 'readable' it is by humans, as long as the protocol can express 
all the present and anticipated variations of the data without breaking 
parsers along the way.

While building the Visual Planner tool, I selected XML output for no 
other reason than it was easy to parse on the receiving end and was 
hierarchical, making it perfect for representing a plan tree - or 
thousands.  I'm sure other alternatives would have been fine as well.  
But, once that decision was made, I never had any reason again to look 
at the XML stream. 

If we're worried about the excess 'weight' of XML, I found this to be a 
non-issue in practice.  The output generated by the 
Visual-Planner-Enabled Postgres server contains MUCH more information 
that one would typically see with standard EXPLAIN.  The tool returns 
not only the most-optimal plan, but all discarded plans as well.  A four 
way join results in output of 24k lines of XML.  While it parses nearly 
instantly, the biggest delay is in the network.  And, even this is minimal.

So, why not put ALL interesting data in the EXPLAIN XML feed?  I'm not 
suggesting for this discussion that we include discarded plans, but that 
we include every piece of data that may be of interest to folks building 
connecting tools.  The parsers can pick and choose what they use easily 
and, because the feed isn't positional, won't break when addition data 
is added.  A GUC parameter could govern the data included in this 
variant of EXPLAIN, but even that seems unnecessary.  This approach will 
allow the standard EXPLAIN to evolve in whatever way pleases the humans 
without interfering with the machines.

Regards,

Tom Raney