Re: Add min and max execute statement time in pg_stat_statement
От | Andrew Dunstan |
---|---|
Тема | Re: Add min and max execute statement time in pg_stat_statement |
Дата | |
Msg-id | 526926AC.9080404@dunslane.net обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Add min and max execute statement time in pg_stat_statement
|
Список | pgsql-hackers |
On 10/23/2013 07:51 PM, Peter Geoghegan wrote: > On Wed, Oct 23, 2013 at 4:46 PM, Josh Berkus <josh@agliodbs.com> wrote: >> So you're suggesting that instead of storing the aggregates as we >> currently do, we store a buffer of the last N queries (in normal form) >> and their stats? And then aggregate when the user asks for it? > No, I'm not. I'm suggesting storing the query texts externally, in a > file. They usually use 1024 bytes of shared memory per entry, > regardless of how long the query text is. This would allow > pg_stat_statements to store arbitrarily large query texts, while also > giving us breathing room if we have ambitions around expanding what > pg_stat_statements can (optionally) track. > > Having said that, I am still pretty sensitive to bloating pg_stat_statements. > Me too. I think min, max and stddev will have a fairly small impact, and give considerable bang for the buck. Not so sure about the other suggestions. And of course, memory impact is only half the story - CPU cycles spent is the other part. I'll be quite happy if we can get around the query text length limit. I have greatly increased the buffer size at quite a few clients, in one case where they run some pretty large auto-generated queries and have memory to burn, up to 40k. cheers andrew
В списке pgsql-hackers по дате отправления: