Re: Add min and max execute statement time in pg_stat_statement

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: Add min and max execute statement time in pg_stat_statement
Дата
Msg-id 20131023162038.GN2706@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: Add min and max execute statement time in pg_stat_statement  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Add min and max execute statement time in pg_stat_statement  (Jeff Janes <jeff.janes@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Sigh, my old HPUX box is totally broken by DSM patch
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Location for external scripts for Extensions?