Re: Add min and max execute statement time in pg_stat_statement

(2013/11/15 11:31), Peter Geoghegan wrote:
> On Thu, Nov 14, 2013 at 6:28 PM, KONDO Mitsumasa
> <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)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)
I think that pg_stat_statements is light-weight monitoring tool, not whole
monitoring tool. This feature is very good for everyone to get statistics.
If you'd like to get more detail statistics, I suggest you to add another
monitoring tools like pg_stat_statements_full. It might more heavy, but it can
get more detail information. Everyone will welcome to new features of that.

> - that spinlock needs to be held for very little time
> indeed to preserve pg_stat_statements current low overhead.
I'd like to leave pg_stat_statement low overhead. My patch realizes it. I don't
add new locks and complicated code in my patch.

> As I said above, lets figure out how to have your tool or a similar
> tool acquire snapshots inexpensively and frequently instead.
We tried to solve this problem using our tool in the past.
However, it is difficult that except log output method which is log_statement=all
option. So we try to add new feature to pg_stat_statement, it would help DBA to
provide useful statistics without overhead.

> 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.
I am also happy to your discussion!
I'd like to install your new patch and give you my comment.

Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center