Skip site navigation (1) Skip section navigation (2)

Re: Getting rid of extra gettimeofday() calls

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Getting rid of extra gettimeofday() calls
Date: 2006-06-19 20:13:28
Message-ID: 1150748009.2587.112.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
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


In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-06-19 20:27:58
Subject: Re: Getting rid of extra gettimeofday() calls
Previous:From: Robert LorDate: 2006-06-19 19:58:48
Subject: Generic Monitoring Framework Proposal

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group