Re: Some belated patch review for "Buffers" explain analyze patch
От | Robert Haas |
---|---|
Тема | Re: Some belated patch review for "Buffers" explain analyze patch |
Дата | |
Msg-id | 603c8f071002100526l66e3577cg1503ddfe15d65c97@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Some belated patch review for "Buffers" explain analyze patch (Greg Stark <stark@mit.edu>) |
Ответы |
Re: Some belated patch review for "Buffers" explain analyze
patch
(Greg Stark <stark@mit.edu>)
|
Список | pgsql-hackers |
On Wed, Feb 10, 2010 at 5:39 AM, Greg Stark <stark@mit.edu> wrote: > On Wed, Feb 10, 2010 at 3:59 AM, Robert Haas <robertmhaas@gmail.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
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Leonardo FДата:
Сообщение: Re: I: About "Our CLUSTER implementation is pessimal" patch
Следующее
От: Priit LaesДата:
Сообщение: [PATCH] Output configuration status after ./configure run.