Re: generic options for explain

David Fetter wrote:
> On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
>
>> Robert Haas <robertmhaas(at)gmail(dot)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