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
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: