Alright, for the next version of this patch I'll look into standard
deviation (an implementation of Welfords' algorithm already exists in
pg_stat_statements).
On 3/4/17 14:18, Peter Eisentraut wrote:
The other problem is that this measures execution time, which can vary
for reasons other than
Hi Julian,
On 3/4/17 8:41 AM, Julian Markwort wrote:
>> Any improvements would be greatly welcome by the admin
>> community, I'm sure.
> That's good to hear - on the other hand, I really appreciate the opinion
> of admins on this idea!
>> However, this is a rather large change which could be desta
Any improvements would be greatly welcome by the admin
community, I'm sure.
That's good to hear - on the other hand, I really appreciate the opinion
of admins on this idea!
However, this is a rather large change which could be destabilizing to
the many users of this extension.
I'm fully aware of
On 1/25/17 12:43, Simon Riggs wrote:
> On 25 January 2017 at 17:34, Julian Markwort
> wrote:
>
>> Analogous to this, a bad_plan is saved, when the time has been exceeded by a
>> factor greater than 1.1 .
> ...and the plan differs?
>
> Probably best to use some stat math to calculate deviation, r
Hi Julian,
On 1/25/17 12:34 PM, Julian Markwort wrote:
> TL:DR;
> We extended the functionality of pg_stat_statements so it can track
> worst and best case execution plans.
pg_stat_statements is an important tool and perhaps one of the most used
core extensions. Any improvements would be greatl
On 25 January 2017 at 17:34, Julian Markwort
wrote:
> Analogous to this, a bad_plan is saved, when the time has been exceeded by a
> factor greater than 1.1 .
...and the plan differs?
Probably best to use some stat math to calculate deviation, rather than fixed %.
Sounds good.
--
Simon Riggs
