Re: Some belated patch review for "Buffers" explain analyze patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Some belated patch review for "Buffers" explain analyze patch
Date
Msg-id 1945.1265764721@sss.pgh.pa.us
Whole thread Raw
In response to Re: Some belated patch review for "Buffers" explain analyze patch  (Greg Stark <stark@mit.edu>)
Responses Re: Some belated patch review for "Buffers" explain analyze patch
List 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 by date:

Previous
From: Fujii Masao
Date:
Subject: Re: TCP keepalive support for libpq
Next
From: Tom Lane
Date:
Subject: Re: Writeable CTEs and empty relations