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 | CAM3SWZQpS_8xfwM6XZkNkXqcVvcVh-CfjyuY3hm8UY4tsLN+Fw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>) |
Ответы |
Re: Add min and max execute statement time in pg_stat_statement
|
Список | pgsql-hackers |
On Thu, Nov 14, 2013 at 6:28 PM, KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp> wrote: > It is confirmation just to make sure, does "this patch" mean my patch? I > agree with you about not adding another lock implementation. It will becomes > overhead. Yes, I referred to your patch. I don't want to go down this road, because aggregation and constructing a timeline feels like the job of another tool. I am concerned about local minima and maxima. Even with the ability to reset min/max independently, you can't do so for each entry individually. And this approach won't scale to a histogram or more sophisticated ways of characterizing distribution, particularly not multiplicatively for things other than execution time (blocks hit and so on) - that spinlock needs to be held for very little time indeed to preserve pg_stat_statements current low overhead. As I said above, lets figure out how to have your tool or a similar tool acquire snapshots inexpensively and frequently instead. That is a discussion I'd be happy to have. IMO pg_stat_statements ought to be as cheap as possible, and do one thing well - aggregate fixed-unit costs cumulatively. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: