On Mon, 2006-06-19 at 11:17 -0400, Tom Lane wrote:
> As of CVS tip, PG does up to four separate gettimeofday() calls upon the
> arrival of a new client command. This is because the statement_timestamp,
> stats_command_string, log_duration, and statement_timeout features each
> independently save an indication of statement start time. Given what
> we've found out recently about gettimeofday() being unduly expensive on
> some hardware, this cries out to get fixed. I propose that we do
> SetCurrentStatementStartTimestamp() immediately upon receiving a client
> message, and then make the other features copy that value instead of
> fetching their own.
Yes. Well spotted. That should make each timed aspect more accurate also
since its the same value.
Presumably you don't mean *every* client message, just stmt start ones.
Can we set that in GetTransactionSnapshot() - that way a serializable
transaction won't need to update the time after each statement. We can
then record this as the SetCurrentSnapshotStartTimestamp().
> Another gettimeofday() call that I would like to get rid of is the one
> currently done at the end of statement when stats_command_string is
> enabled: we record current time when resetting the activity_string to
> <IDLE>. Would anyone be terribly upset if this used statement_timestamp
> instead? The effect would be that for an idle backend,
> pg_stat_activity.query_start would reflect the start time of its latest
> query instead of the time at which it finished the query. I can see
> some use for the current behavior but I don't really think it's worth
> the overhead of a gettimeofday() call.
Presumably we have to do at least one at the end when doing statement
logging?
I notice there is also one in elog.c for when we have %t set. We
probably don't need to do both when statement logging.
> Preliminary tests say that after the shared-memory change I committed
> yesterday, the overhead of stats_command_string consists *entirely*
> of the two added gettimeofday() calls.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com
