Re: [HACKERS] pow support for pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] pow support for pgbench
Date: 2017-12-26 22:26:58
Message-ID: alpine.DEB.2.20.1712262320160.22976@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Robert,

>>> 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.
>
> This version looks good to me, except that I wonder if we should try to
> switch to the floating-point version if the integer version would/does
> overflow.

My 0.02€ is that it is under the user control who provides either ints or
doubles as arguments. So I do not think that we should bother, for what my
opinion is worth.

If this is a new requirement, detecting the integer overflow is probably
possible with some testing, eg unexpected changes of sign, but that would
probably add two tests per round, and probably double the computation
cost.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message legrand legrand 2017-12-26 22:43:36 Re: AS OF queries
Previous Message Jeff Janes 2017-12-26 21:52:36 Re: AS OF queries