Re: Add min and max execute statement time in pg_stat_statement - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id CAM3SWZQpS_8xfwM6XZkNkXqcVvcVh-CfjyuY3hm8UY4tsLN+Fw@mail.gmail.com
Whole thread Raw
In response to Re: Add min and max execute statement time in pg_stat_statement  (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>)
Responses Re: Add min and max execute statement time in pg_stat_statement  (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>)
List 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 by date:

Previous
From: KONDO Mitsumasa
Date:
Subject: Re: Optimize kernel readahead using buffer access strategy
Next
From: Michael Paquier
Date:
Subject: REINDEX CONCURRENTLY 2.0