Re: pg_stat_statements: calls under-estimation propagation
Daniel Farina <daniel@fdr.io>
From: Daniel Farina <daniel@fdr.io>
To: Sameer Thakur <samthakur74@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>, pg@heroku.com
Date: 2013-09-30T05:58:58Z
Lists: pgsql-hackers
On Sun, Sep 29, 2013 at 10:25 AM, Sameer Thakur <samthakur74@gmail.com> wrote: > Yes i was. Just saw a warning when pg_stat_statements is loaded that > valid values for pg_stat_statements.max is between 100 and 2147483647. > Not sure why though. I remember hacking that out for testing sake. I can only justify it as a foot-gun to prevent someone from being stuck restarting the database to get a reasonable number in there. Let's CC Peter; maybe he can remember some thoughts about that. Also, for onlookers, I have changed this patch around to do the date-oriented stuff but want to look it over before stapling it up and sending it. If one cannot wait, one can look at https://github.com/fdr/postgres/tree/queryid. The squashed-version of that history contains a reasonable patch I think, but a re-read often finds something for me and I've only just completed it yesterday.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Improve management of "sticky" entries in contrib/pg_stat_statements.
- d5375491f8e3 9.2.0 cited