Re: pg_stat_statements and planning time
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-03-07T16:07:08Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Allow pg_stat_statements to track planning statistics.
- 17e03282241c 13.0 landed
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? 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. regards, tom lane