On Thu, Jan 30, 2014 at 12:32 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
