Greg Stark <st...@mit.edu> writes:
> On Wed, Feb 10, 2010 at 12:32 AM, Tom Lane <t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
