On Wed, Oct 23, 2013 at 1:07 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > How does max not answer "is this query ever really slow?"? But good point, > if we have a max, then I think a time-stamp for when that max was obtained > would also be very useful.
I'm concerned about the cost of all of this. And like Stephen, I'm not too impressed by the idea of a permanent max - it's going to be some value from before the cache was warmed the large majority of the time. I think that there are some big savings to be made now that the query text is only useful to humans, and isn't compared directly for the purposes of matching and so on. Generally speaking, a human will inquire about query execution costs far less frequently than the system spends aggregating them. So fixing that problem would go a long way towards resolving these concerns. It would also probably have the benefit of making it possible for query texts to be arbitrarily long - we'd be storing them in files (with a shared memory buffer). I get a lot of complaints about the truncation of query texts in pg_stat_statements, so I think that'd be really valuable. It would make far higher pg_stat_statements.max values practical to boot, by radically reducing the amount of shared memory required. All of this might be a bit tricky, but I suspect it's well worth it. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers