Re: machine-readable explain output - Mailing list pgsql-hackers

On Tue, Jun 16, 2009 at 1:21 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Jun 16, 2009 at 12:04 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> FWIW, I like Greg's idea of subdividing the available data this way.
>
>> I like it too, but I'd like to see us come up with a design that
>> allows it to be used for all of the output formats (text, XML, and
>> JSON).  I think it we should be looking for a way to allow modules to
>> publish abstract objects like property-value mappings, or lists of
>> strings, rather than thinking strictly in terms of XML.  If we have a
>> module called foo that emits property bar with value baz and property
>> bletch with value quux, then ...
>
> This seems to be missing the point I was trying to make, which is that
> a design like that actually offers no leverage at all: if you don't know
> all about foo to start with, you have no idea what to do with either bar
> or bletch.  You can *parse* the data, since it's in XML or JSON or
> whatever, but you don't know what it is.
>
> The EXPLAIN problem is a fairly constrained universe: there is going to
> be a tree of plan nodes, there are going to be some static properties of
> each plan node, and there may or may not be various sorts of estimates
> and/or measurements attached to each one.  What I'm after is that code
> examining the output can know "oh, this is a measurement" even if it
> hasn't heard of the particular kind of measurement.
>
> As a concrete example of what I'm thinking about, I'd hope that PgAdmin
> would be able to display a graphical summary of a plan tree, and then
> pop up measurements associated with one of the nodes when you
> right-click on that node.  To do this, it doesn't necessarily have to
> know all about each specific measurement that a particular backend
> version might emit; but it needs to be able to tell which things are
> measurements.

*scratches head*

So you're looking for a way to categorize the data that appear in the
output by type, like any given piece of data is either a measurement,
an estimate, or a part of the plan structure?

It seems to me that with a sufficiently powerful API, add-on modules
could emit arbitrary stuff that might not fall into the categories
that you've mentioned.  For example, there was a previous EXPLAIN XML
patch which contained a bunch of code that spit out plans that were
considered but not chosen.  And there could easily be other kinds of
less invasive add-ons that would still want to emit properties that
are formatted as text or lists rather than measurements per se.

I think it's kind of hopeless to think that a third-party module is
going to be able to do much better than to display any unexpected
properties whose value is just text and punt any unexpected properties
whose value is a complex object (nested tags in XML-parlance, hash in
JSON).

I have a feeling I'm still missing the point here...

...Robert