On Sun, Jul 17, 2016 at 7:15 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Peter Geoghegan <p...@heroku.com> writes: >> On Sun, Jul 17, 2016 at 12:22 AM, Jun Cheol Gim <dialog...@gmail.com> wrote: >>> If we have timestamp of first and last executed, we can easily gather thess >>> informations and there are tons of more use cases. > >> -1 from me. > >> I think that this is the job of a tool that aggregates things from >> pg_stat_statements. It's unfortunate that there isn't a good >> third-party tool that does that, but there is nothing that prevents >> it. > > The concern I've got about this proposal is that the results get very > questionable as soon as we start dropping statement entries for lack > of space. last_executed would be okay, perhaps, but first_executed > not so much.
ISTM that last_executed is useful - you can then see for yourself which of the statements that you see in the pg_stat_statements output have been issued recently, and which are older. I mean, you could also do that, as Peter says, with an additional tool that takes periodic snapshots of the data and then figures out an approximate last_executed time, but if you had this, you wouldn't need an additional tool, at least not for simple cases. Better yet, the data would be more exact. I dunno what's not to like about that, unless we're worried that tracking it will incur too much overhead. first_executed doesn't seem as useful as last_executed, but it isn't useless either. It can't properly be read as the first time that statement was ever executed, but it can be properly read as the amount of time that has passed during which that statement has been executed frequently enough to stay in the hash table, which is something that someone might want to know. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
