Re: Add min and max execute statement time in pg_stat_statement - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id 20131023162038.GN2706@tamriel.snowman.net
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Add min and max execute statement time in pg_stat_statement  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Josh,

* Josh Berkus (josh@agliodbs.com) wrote:
> On the other hand, it's still true that a high STDDEV indicates a high
> variance in the response times of a particular query, whereas a low one
> indicates that most are close to the average.  While precision math
> might not work if we don't have the correct distribution, for gross DBA
> checks it's still useful.  That is, I can answer the question in many
> cases of: "Does this query have a high average because of outliers, or
> because it's consisently slow?" by looking at the STDDEV.

The concern is actually the reverse issue- often the question is "is
this query ever really slow?", or "when is this query really slow?" and
those questions are not answered by stddev, min, max, nor avg.

> And FWIW, for sites where we monitor pg_stat_statements, we reset daily
> or weekly.  Otherwise, the stats have no meaning.

I have wondered if we (PG) should do that by default..  I agree that
often they are much more useful when reset periodically.  Of course,
having actual historical information *would* be valuable, if you could
identify the time range covered..
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Sigh, my old HPUX box is totally broken by DSM patch
Next
From: Josh Berkus
Date:
Subject: Re: Location for external scripts for Extensions?