Re: Add min and max execute statement time in pg_stat_statement

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: Add min and max execute statement time in pg_stat_statement
Дата
Msg-id 54972471.7080306@dunslane.net
обсуждение исходный текст
Ответ на Re: Add min and max execute statement time in pg_stat_statement  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Add min and max execute statement time in pg_stat_statement  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On 12/21/2014 02:12 PM, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> On 12/21/2014 01:23 PM, Alvaro Herrera wrote:
>>> The point, I think, is that without atomic instructions you have to hold
>>> a lock while incrementing the counters.
>> Hmm, do we do that now?
> We already have a spinlock mutex around the counter adjustment code, so
> I'm not sure why this discussion is being held.

Because Peter suggested we might be able to use atomics. I'm a bit 
dubious that we can for min and max anyway.

>
>> I would like someone more versed in numerical analysis than me to
>> tell me how safe using sum of squares actually is in our case.
> That, on the other hand, might be a real issue.  I'm afraid that
> accumulating across a very long series of statements could lead
> to severe roundoff error in the reported values, unless we use
> a method chosen for numerical stability.
>
>             


Right.

The next question along those lines is whether we need to keep a running 
mean or whether that can safely be calculated on the fly. The code at 
<http://www.johndcook.com/blog/standard_deviation/> does keep a running 
mean, and maybe that's required to prevent ill conditioned results, 
although I'm quite sure I see how it would. But this isn't my area of 
expertise.

cheers

andrew



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Следующее
От: Noah Misch
Дата:
Сообщение: Re: Final Patch for GROUPING SETS