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
|
Список | 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 по дате отправления: