Re: pgsql: Add stats for min, max, mean, stddev times to pg_stat_statements - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Add stats for min, max, mean, stddev times to pg_stat_statements
Date
Msg-id 2182.1427503133@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Add stats for min, max, mean, stddev times to pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: Fix whitespace
Next
From: Heikki Linnakangas
Date:
Subject: pgsql: Add index-only scan support to inet GiST opclass.