Re: [HACKERS] pow support for pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(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-22 09:50:14
Message-ID: alpine.DEB.2.20.1712221035190.7724@lancre
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers


>> 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.


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.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Teodor Sigaev 2017-12-22 10:09:09 Re: [HACKERS] pgbench more operators & functions
Previous Message Antonin Houska 2017-12-22 09:45:50 Suspicious call of initial_cost_hashjoin()