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.
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.
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. If we get rid of both, the
difference between having stats_command_string on and off is barely
measurable (using Bruce's test case of 10000 "SELECT 1;" statements).
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
