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

From Jeff Janes
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id CAMkU=1xc5595L6zx=D5SbVNY6HKbdiVS1KYjJ=ShdH0KPy8aLg@mail.gmail.com
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Add min and max execute statement time in pg_stat_statement  (Stephen Frost <sfrost@snowman.net>)
Re: Add min and max execute statement time in pg_stat_statement  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Wed, Oct 23, 2013 at 9:20 AM, Stephen Frost <sfrost@snowman.net> wrote:
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.

How does max not answer "is this query ever really slow?"?  But good point, if we have a max, then I think a time-stamp for when that max was obtained would also be very useful.


Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: missing locking in at least INSERT INTO view WITH CHECK
Next
From: Andres Freund
Date:
Subject: Re: missing locking in at least INSERT INTO view WITH CHECK