Re: generic options for explain

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I think we are going in the wrong direction. No one has said that
> they want a machine-readable EXPLAIN format. OK, there are
> historically about three people that want one, but they have already
> solved the problem of parsing the current format.

Well, obviously the set of tool designers is smaller than the set of
casual users of EXPLAIN, but their problems are none the less real and
very important.

> What people really want is optional additional information in the human-
> readable format. Giving them a machine readable format does not solve the
> problem.

Actually, the exact problem is this: those two goals are in conflict.
There'd be little objection to adding any random set of optional stuff
to EXPLAIN's textual output, if it weren't for the fact that it would
make machine parsing of that output even harder than it is already.

So my feeling is that we need a machine-readable format containing all
the data in order to satisfy the needs of tool designers. Once they
are freed from having to parse EXPLAIN's textual output, we can whack
the textual output around all we want. (Which kills my previous
argument that we only need one new option, but such is life.)

Now there is a third set of desires having to do with being able to do
simple SQL-based analysis of EXPLAIN output. That's the piece I think
we don't have a good handle on. In particular, it's not clear whether
a SQL-friendly output format can be the same as either of the other
two. (I don't personally find this goal very compelling --- there is
no natural law saying that SQL is a good tool for analyzing EXPLAIN
output --- but I'm willing to look at it to see if it's feasible.)

regards, tom lane