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
|
Список | 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 по дате отправления: