Re: Add min and max execute statement time in pg_stat_statement
От | Peter Geoghegan |
---|---|
Тема | Re: Add min and max execute statement time in pg_stat_statement |
Дата | |
Msg-id | CAM3SWZSH8jC+a+hegGNpF2H9FywMKVnAj9R3ocrH=jDp1McBxA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
On Thu, Nov 14, 2013 at 9:09 AM, Fujii Masao <masao.fujii@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
В списке pgsql-hackers по дате отправления: