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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
