Re: Add min and max execute statement time in pg_stat_statement

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Add min and max execute statement time in pg_stat_statement
Дата
Msg-id CAM3SWZSEa0Mhq1YYdCcG3Grz3-=xAOddRB+ixB86AywuzpW=SA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add min and max execute statement time in pg_stat_statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add min and max execute statement time in pg_stat_statement  (Mitsumasa KONDO <kondo.mitsumasa@gmail.com>)
Список pgsql-hackers
On Thu, Jan 30, 2014 at 12:32 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In reality, actual applications
>> could hardly be further from the perfectly uniform distribution of
>> distinct queries presented here.
>
> Yeah, I made the same point in different words.  I think any realistic
> comparison of this code to what we had before needs to measure a workload
> with a more plausible query frequency distribution.

Even though that distribution just doesn't square with anybody's
reality, you can still increase the pg_stat_statements.max setting to
10k and the problem goes away at little cost (a lower setting is
better, but a setting high enough to cache everything is best). But
you're not going to have terribly much use for pg_stat_statements
anyway....if you really do experience churn at that rate with 5,000
possible entries, the module is ipso facto useless, and should be
disabled.


-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Regression tests failing if not launched on db "regression"
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication