Re: pg_stat_statements and planning time

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_statements and planning time
Date: 2012-03-07 16:07:08
Message-ID: 8309.1331136428@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2012-03-07 16:09:45 Re: a slightly stale comment
Previous Message Pavel Stehule 2012-03-07 15:55:12 Re: review: CHECK FUNCTION statement