On Thu, Nov 14, 2013 at 6:28 PM, KONDO Mitsumasa <kondo.mitsum...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
