Re: pg_stat_statements and planning time

On Thu, Mar 8, 2012 at 1:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)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?

Agreed, it's more intuitive for a user.

Along with "total_time" and "plan_time", should we also define "exec_time"
reporting only the execution time for improvement of usability though it can
be calculated from "total_time" and "plan_time"?

> 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.

Agreed to add something like "plan_count" column. This also would be helpful
for e.g., tuning the prepareThreshold parameter in JDBC.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center