Re: Some belated patch review for "Buffers" explain analyze patch
От | Robert Haas |
---|---|
Тема | Re: Some belated patch review for "Buffers" explain analyze patch |
Дата | |
Msg-id | 603c8f071002091959q23e006afkcbf9e352791aad53@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Some belated patch review for "Buffers" explain analyze patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Some belated patch review for "Buffers" explain analyze
patch
|
Список | pgsql-hackers |
On Tue, Feb 9, 2010 at 10:51 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Feb 9, 2010 at 8:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> ... I wouldn't object to adding a "total time" field to the >>> machine-readable formats. > >> One possibility we discussed previously is to add some decimal places >> to the relevant values when nloops > 1. > > Hmm, I must've missed that conversation, but it seems like a possibly > workable compromise. http://archives.postgresql.org/pgsql-hackers/2009-05/msg01419.php >> If we're going to add a total time field, I think we should add it to >> both the machine-readable and human-readable formats. I know it's a >> little long-winded, but one of the things that I find really >> unfortunate about the current format is that it's sometimes hard to >> look at a plan tree and figure out where "the slow part" is, because >> some things have been divided through by the number of loops. Reading >> through the JSON or YAML format to find the data is, I guess, better >> than nothing, but only slightly: I frequently deal with plans that are >> 25-30 lines long: in XML format, those will be 250-300 lines long. I >> wouldn't mind having to do EXPLAIN (ANALYZE, VERBOSE) or EXPLAIN >> (ANALYZE, some-other-option) to get the details, but EXPLAIN (ANALYZE, >> FORMAT XML) ... is not really a direction I want to go. > > I don't really buy this line of reasoning. You don't want to read the > XML format because it's too long, so your solution is to make the text > format longer? 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. That's OK, because that's not what they're for. But do I want a format this IS intended to be readable by human beings and also contains all the relevant information? Definitely. ...Robert
В списке pgsql-hackers по дате отправления: