Re: Some belated patch review for "Buffers" explain analyze patch

On Wed, Feb 10, 2010 at 5:39 AM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> Yes.  We could add every bell and whistle imaginable to the text
>> format and it still would not begin to approach the verbosity of the
>> machine-readable formats.  Have you looked at them on a complex plan?
>> They are really, really long, and in many cases quite unreadable by
>> human beings.
>
> Well I complained about that at the time. At least for XML that's
> becuase you chose to make separate tags on separate lines for every
> single value instead of just having one tag for estimates, one for
> actual, and using attributes for the different values.

I had some reasons for that decision which I still believe are valid -
namely, not wanting to have completely custom code for every output
format. You're free to disagree with that decision, of course.

That's also definitely not the only problem. For example, EXPLAIN
(VERBOSE, FORMAT JSON) is often ridiculously wide because each output
list is printed on a single line. The text format has that problem
too, but it's much worse in JSON because of the extra punctuation and
separators. Now I could fix that by printing each output item on its
own line, but then the output would be even more ridiculously long
than it is already. Probably the only readable way to do this is to
add some logic to keep printing items on a single line until we run
out of columns, and then jump down to the next line. But I have a
feeling that a patch to add word-wrap logic to a machine-readable
output format would be DOA as far as Tom is concerned, and I can't say
I disagree.

> Incidentally my patch to use getrusage also reraises the other issue I
> complained about. There's no organization to the tags so a tool to
> view them can't make heads or tails of them without knowing in advance
> what they all are. For example pgadmin can't make a tree with
> expandable subtrees for each data source since it doesn't know which
> attributes are related to which unless it hard codes knowledge about
> them.

I would guess that it's possible to find a way to fix or improve on
this, but I'm not sure whether there's support for doing that at this
point in the cycle, or agreement on what it should look like.

I'm aware that there are a number of people who are not happy with the
way I implemented that patch for a number of different reasons. Of
course, I like it best when everyone thinks that my work is the bees
knees, but the threads about this patch were long and very many people
expressed very many mutually contradictory opinions about how I ought
to change things. I did the best I could to come up with something
that was useful to me and acceptable to the community.

Or as I said at the time... nobody liked anything about the patch
except that they didn't have to write it.

...Robert