On Thu, Nov 14, 2013 at 9:09 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> I think that pg_stat_statements should be made to do this kind of >> thing by a third party tool that aggregates snapshots of deltas. >> Time-series data, including (approximate) *local* minima and maxima >> should be built from that. I think tools like KONDO-san's pg_statsinfo >> tool have an important role to play here. I would like to see it or a >> similar tool become a kind of defacto standard for consuming >> pg_stat_statements' output.
> Agreed. I would like to hear others' thoughts on how to proceed here. Has anyone actually tried and failed with an approach that uses aggressive aggregation of snapshots/deltas? If that's something that is problematic, let's hear why. Maybe pg_stat_statements could do better when snapshots are aggressively taken by tools at fixed intervals. Most obviously, we could probably come up with a way better interface for tools that need deltas only, where a consumer registers interest in receiving snapshots. We could store a little bitmap structure in shared memory, and set bits as corresponding pg_stat_statements entries are dirtied, and only send query texts the first time. I am still very much of the opinion that we need to expose queryid and so on. I lost that argument several times, but it seems like there is strong demand from it from many places - I've had people that I don't know talk to me about it at conferences. -- 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
