Re: Add min and max execute statement time in pg_stat_statement
От | Tom Lane |
---|---|
Тема | Re: Add min and max execute statement time in pg_stat_statement |
Дата | |
Msg-id | 10176.1391038198@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Add min and max execute statement time in pg_stat_statement (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Add min and max execute statement time in pg_stat_statement
|
Список | pgsql-hackers |
Andrew Dunstan <andrew@dunslane.net> writes: > I could live with just stddev. Not sure others would be so happy. FWIW, I'd vote for just stddev, on the basis that min/max appear to add more to the counter update time than stddev does; you've got this: + e->counters.total_sqtime += total_time * total_time; versus this: + if (e->counters.min_time > total_time || e->counters.min_time == EXEC_TIME_INIT) + e->counters.min_time = total_time; + if (e->counters.max_time < total_time) + e->counters.max_time = total_time; I think on most modern machines, a float multiply-and-add is pretty darn cheap; a branch that might or might not be taken, OTOH, is a performance bottleneck. Similarly, the shared memory footprint hit is more: two new doubles for min/max versus one for total_sqtime (assuming we're happy with the naive stddev calculation). If we felt that min/max were of similar value to stddev then this would be mere nitpicking. But since people seem to agree they're worth less, I'm thinking the cost/benefit ratio isn't there. regards, tom lane
В списке pgsql-hackers по дате отправления: