| From: | Peter Geoghegan <pg(at)heroku(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, Mitsumasa KONDO <kondo(dot)mitsumasa(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Add min and max execute statement time in pg_stat_statement |
| Date: | 2014-01-30 21:22:29 |
| Message-ID: | CAM3SWZSEa0Mhq1YYdCcG3Grz3-=xAOddRB+ixB86AywuzpW=SA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 30, 2014 at 12:32 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2014-01-30 21:36:30 | Re: Patch: show xid and xmin in pg_stat_activity and pg_stat_replication |
| Previous Message | Robert Haas | 2014-01-30 21:09:31 | Re: Regression tests failing if not launched on db "regression" |