Re: [HACKERS] pow support for pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] pow support for pgbench
Date
Msg-id alpine.DEB.2.20.1712221035190.7724@lancre
Whole thread Raw
In response to Re: [HACKERS] pow support for pgbench  (Raúl Marín Rodríguez <rmrodriguez@carto.com>)
List pgsql-hackers
Hello,

>> If a double is always returned, I'm wondering whether keeping the ipow
>> version makes much sense: In case of double loss of precision, the
>> precision is lost, too bad, and casting back to int won't bring it back.
>
> I've kept it because knowing that both are ints enables not making a lot of
> checks (done in math.h pow) so it's way faster. In my system it's 2-3ns vs
> ~40ns. I'm willing to settle for using just pow() if that makes it clearer.

Ok, performance is a good argument. I would not have thought that the 
double performance would be so bad, but probably no miracle.

As of precision, there is another case where the int computation 
overflows, so that the int result is stupid and the double version is a 
better approximation. Now that can be controled by providing double or int 
arguments to the function, so for me it is ok.

> Attached the  updated patch.

Ok.

I have marked it as ready to committer.

Basically for me this is an inferior version, not specially behaving that 
better with respect to SQL, but if it eventually gets through a committer 
maybe it is worth it.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Suspicious call of initial_cost_hashjoin()
Next
From: Teodor Sigaev
Date:
Subject: Re: [HACKERS] pgbench more operators & functions