Re: pg_stat_statements: calls under-estimation propagation
Sameer Thakur <samthakur74@gmail.com>
From: Sameer Thakur <samthakur74@gmail.com>
To: Daniel Farina <daniel@heroku.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2013-10-03T08:11:29Z
Lists: pgsql-hackers
Attachments
- pg_stat_statements-identification-v7.patch.gz (application/x-gzip) patch v7
On Wed, Oct 2, 2013 at 6:40 PM, Sameer Thakur <samthakur74@gmail.com> wrote: >> >> Looks pretty good. Do you want to package up the patch with your >> change and do the honors and re-submit it? Thanks for helping out so >> much! > Sure, will do. Need to add a bit of documentation explaining > statistics session as well. > I did some more basic testing around pg_stat_statements.max, now that > we have clarity from Peter about its value being legitimate below 100. > Seems to work fine, with pg_stat_statements =4 the max unique queries > in the view are 4. On the 5th query the view holds just the latest > unique query discarding the previous 4. Fujii had reported a > segmentation fault in this scenario. > Thank you for the patch Please find the patch attached regards Sameer
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