Re: pgsql: Add stats for min, max, mean, stddev times to pg_stat_statements
В списке pgsql-committers по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: pgsql: Add stats for min, max, mean, stddev times to pg_stat_statements |
| Дата | |
| Msg-id | 2182.1427503133@sss.pgh.pa.us обсуждение |
| Ответ на | Re: pgsql: Add stats for min, max, mean, stddev times to pg_stat_statements (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-committers |
I wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> However, it is moaning about the code in the sqrtd() function. I'm
>> wondering if we shouldn't just rip that out and use the library sqrt()
>> function. It's not called for every statement processed, only each time
>> the function is called (for each row).
> [ looks... ] +1. I'm skeptical that that's even a win at all on modern
> hardware; sqrt() is a primitive operation on nearly anything these days.
I did some quick comparisons on a reasonably current server
(Xeon E5-2609 running RHEL6.6), and found that this:
volatile double x;
volatile double y = 1.23456;
for (i = 0; i < n; i++)
{
x = sqrtd(y);
}
takes about 5.6 nsec per iteration, while with plain sqrt() it's
about 8.8 nsec. So while there is a measurable gain (on this hardware
anyway) IMO it is absolutely not worth taking any portability risks for.
regards, tom lane
В списке pgsql-committers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера