Re: Add min and max execute statement time in pg_stat_statement

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Add min and max execute statement time in pg_stat_statement
Дата
Msg-id CAMkU=1xc5595L6zx=D5SbVNY6HKbdiVS1KYjJ=ShdH0KPy8aLg@mail.gmail.com
обсуждение исходный текст
Ответ на 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  (Stephen Frost <sfrost@snowman.net>)
Re: Add min and max execute statement time in pg_stat_statement  (Peter Geoghegan <pg@heroku.com>)
Список 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 по дате отправления:

Предыдущее
От: Dean Rasheed
Дата:
Сообщение: Re: missing locking in at least INSERT INTO view WITH CHECK
Следующее
От: Andres Freund
Дата:
Сообщение: Re: missing locking in at least INSERT INTO view WITH CHECK