Ühel kenal päeval, E, 2006-06-19 kell 11:17, kirjutas Tom Lane:
> 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
> indepen
Simon Riggs <[EMAIL PROTECTED]> writes:
> Presumably you don't mean *every* client message, just stmt start ones.
At the moment I've got it setting the statement_timestamp on receipt of
any message that could lead to execution of user-defined code; that
includes Query, Parse, Bind, Execute, Funct
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 a
On Mon, Jun 19, 2006 at 11:17:48AM -0400, Tom Lane wrote:
> 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 bu
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 fou
