Re: Some belated patch review for "Buffers" explain analyze patch
От | Tom Lane |
---|---|
Тема | Re: Some belated patch review for "Buffers" explain analyze patch |
Дата | |
Msg-id | 1945.1265764721@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | 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
|
Список | pgsql-hackers |
Greg Stark <stark@mit.edu> writes: > On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> The reason that EXPLAIN prints things the way it does is so that actual >> costs/times are comparable to estimated costs. > Oh, that was a thought I had along the way but forgot to mention in my > email: since the buffer usage isn't related to the cost there isn't > nearly the impetus to divide by loops except to be consistent with the > time. True. BTW I realized that I was confusing the buffer-usage issue with the recent changes to add printing of hash join execution stats. I believe offhand that for both that and the Sort statistics, what you see is really just stats for the *last* execution of the node, if it got executed more than once. While that's incomplete, at least it is somewhat consistent --- you won't see numbers that are stated on a completely different basis from those around them. We'd have to think about whether and how to adjust the sort and hashjoin stats if we wanted to switch over to whole-query totals. > Perhaps instead of looking to change the "actual" times we should look > at a way to include total time spent in each node. You can already get that by multiplying the displayed total time by the number of loops. Robert does have a point that this is subject to a lot of roundoff error, though, when the per-loop time is much less than 1 msec. I wouldn't object to adding a "total time" field to the machine-readable formats. regards, tom lane
В списке pgsql-hackers по дате отправления: