Re: Some belated patch review for "Buffers" explain analyze patch
От | Greg Stark |
---|---|
Тема | Re: Some belated patch review for "Buffers" explain analyze patch |
Дата | |
Msg-id | 407d949e1002100609x460765b9i2b0d6862b20ddd4@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Some belated patch review for "Buffers" explain analyze patch (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Some belated patch review for "Buffers" explain analyze
patch
|
Список | pgsql-hackers |
On Wed, Feb 10, 2010 at 1:26 PM, Robert Haas <robertmhaas@gmail.com> wrote: > For example, EXPLAIN (VERBOSE, FORMAT JSON) is often ridiculously > wide because each output list is printed on a single line. Perhaps this is just a terminology difference but it seems ridiculously *narrow* to me: QUERY PLAN --------------------------------------[ + { + "Plan":{ + "Node Type": "Seq Scan", + "Relation Name": "i", + "Schema":"public", + "Alias": "i", + "Startup Cost": 0.00, + "Total Cost":63344.86, + "Plan Rows": 2399986, + "Plan Width": 101, + "Actual Startup Time":0.115, + "Actual Total Time": 3259.839,+ "Actual Rows": 2400000, + "Actual Loops": 1, + "Output": ["i"] + }, + "Triggers": [ + ], + "Total Runtime": 5977.303 + } +] (1 row) > Or as I said at the time... nobody liked anything about the patch > except that they didn't have to write it. I know I am often paralyzed by not being certain what the perfect choice is and I think the project as a whole suffers from that sometime. XML explain output was on the agenda for years but was stalled because we weren't sure what XML schema would be useful. And we couldn't find out what XML schema would be useful until we had some tools trying to use the data.... If pgadmin tries to use the xml data and comes back with some feedback will we be able to rejigger the schema? Will pgadmin be happy with a different xml schema for each version? I suppose this depends in part with how powerful the xml schema parsers are these days, my understanding is that they're complex but that doesn't necessarily translate into being powerful. -- greg
В списке pgsql-hackers по дате отправления: