On Thu, Mar 8, 2012 at 1:07 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fu...@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?
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
