On Wed, Mar 7, 2012 at 8:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> In the patch, I didn't change the column name "total_time" meaning
>> the time spent in the executor because of the backward compatibility.
>> But once new column "plan_time" is added, "total_time" is confusing and
>> ISTM it should be renamed...
>
> Well, if we were tracking planning time, what I would expect
> "total_time" to mean is plan time plus execution time. Should it be
> redefined that way, instead of renaming it?
I think you are right.
On first glance, a user would only be interested in one number, the
total time. Most people are hunting queries that happen
(surprisingly) frequently and don't have good indexes in place to
serve them, and in those cases planning time is negligible. However,
should planning time be the bottleneck then one has to investigate
fewer, smaller queries, a very different solution space.
> Another point here is that because of plan caching, the number of
> planner invocations could be quite different from the number of executor
> runs. It's not clear to me whether this will confuse matters for
> pg_stat_statements, but it's something to think about. Will it be
> possible to tell whether a particular statement is hugely expensive to
> plan but we don't do that often, versus cheap to plan but we do that a
> lot? IOW I am wondering if we need to track the number of invocations
> as well as total time.
I don't think tracking a few more words will do much harm, and could
also do a lot of good....perhaps count, sum, sum(x**2) of planning and
execution?
(Few things to me are more annoying than an unadorned average when it
would have been feasible to take a square of a number).
Thoughts?
--
fdr