Re: Less than ideal error reporting in pg_stat_statements
Peter Geoghegan <pg@heroku.com>
From: Peter Geoghegan <pg@heroku.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jim Nasby <Jim.Nasby@bluetreble.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2015-10-04T20:25:21Z
Lists: pgsql-hackers
On Sun, Oct 4, 2015 at 1:12 PM, Peter Geoghegan <pg@heroku.com> wrote: > On Sun, Oct 4, 2015 at 1:01 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Ah, right, sorry. I meant to make its result match what gc_texts would >> get, by not falsely counting entries with dropped texts. That's not >> what you have in your patch but it seems like an easy enough fix. > > I'm trying to make mean_query_len representative of *useful* entry > query length. I guess I don't have that within gc_texts in my patch, > but I do have it within entry_dealloc (up to and including considering > dropped texts), which FWIW is far more important. To be clear: I wasn't sure why you though I falsely count entries with dropped texts within entry_dealloc(). I suppose my sense was that dropped texts ought to not make garbage collection occur too frequently, which could also be a problem. Garbage collection ought to occur when the size of the query text file becomes excessive relative to useful entries. I was worried about the thrashing risk from dropped text entries. Maybe we could, as an alternative, not forget the original size of dropped query texts, relying only on their offset to indicate the text is invalid. Dropped query texts would then not be special in that sense, which seems like a good thing all around. -- Peter Geoghegan
Commits
-
Be more wary about 32-bit integer overflow in pg_stat_statements.
- c67c2e2a2939 16.0 landed
- dd414bf4e047 10.22 landed
- 82ebc70d1c7f 15.0 landed
- 6b67db10c366 13.8 landed
- 6608a4305636 12.12 landed
- 17fd203b414e 14.5 landed
- 06f6a07ba465 11.17 landed