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

From KONDO Mitsumasa
Subject Re: Add min and max execute statement time in pg_stat_statement
Date
Msg-id 53159EF9.10704@lab.ntt.co.jp
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  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Hi all,

I think this patch is completely forgotten, and feel very unfortunate:(

Min, max, and stdev is basic statistics in general monitoring tools,
So I'd like to push it.

(2014/02/12 15:45), KONDO Mitsumasa wrote:
>> (2014/01/29 17:31), Rajeev rastogi wrote:
>>> No Issue, you can share me the test cases, I will take the performance report.
> Attached patch is supported to latest pg_stat_statements. It includes min, max,
> and stdev statistics. Could you run compiling test on your windows enviroments?
> I think compiling error was fixed.
>
> We had disscuttion about which is needed useful statistics in community, I think
> both of statistics have storong and weak point. When we see the less(2 or 3)
> executed statement, stdev will be meaningless because it cannot calculate
> estimated value precisely very much, however in this situation, min and max will
> be propety work well because it isn't estimated value but fact value. On the
> other hand, when we see the more frequency executed statement, they will be
> contrary position
> statistics, stdev will be very useful statistics for estimating whole statements,
> and min and max might be extremely value.
> At the end of the day, these value were needed each other for more useful
> statistics when we want to see several actual statments. And past my experience
> showed no performance problems in this patch. So I'd like to implements all these
> values in pg_stat_statements.

Regards,
--
Mitsumasa KONDO
NTT Open Source Software Center




pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: ALTER TABLE lock strength reduction patch is unsafe
Next
From: Peter Geoghegan
Date:
Subject: Re: jsonb and nested hstore