On Tue, Dec 26, 2017 at 4:45 PM, Raúl Marín Rodríguez
wrote:
> I've implemented the overflow checks and made some benchmarks and the ipow()
> version became slower except with some specific inputs (base 0 for example).
> It's true that the new auxiliary functions could be optimized, but I don't
>
Bonjour Michaël,
And my 2c on the matter is that switching silently from one version to
the other would be unwelcome. The user should be aware if a test is
overflowing a number when specifying an integer.
This whole integer pow version is becoming unduly complicated and ugly.
For me, the rat
On Tue, Dec 26, 2017 at 11:26:58PM +0100, Fabien COELHO wrote:
> > 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
Hi,
I've implemented the overflow checks and made some benchmarks and the
ipow() version became slower except with some specific inputs (base 0 for
example). It's true that the new auxiliary functions could be optimized,
but I don't think it makes sense to keep working on them just to match
pow()
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
On Fri, Dec 22, 2017 at 12:46 AM, Raúl Marín Rodríguez
wrote:
>> 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
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
Hi Fabien,
Thanks for the review.
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
Hello Raúl,
v7 needs a rebase.
Also, you might try to produce a version which is compatible with Robert's
constraints.
My 0.02€ on this new version: Applies cleanly, compiles and works.
I cannot say that I like it more than the previous version.
If a double is always returned, I'm wonderin
Hi,
Rebased the patch on top of current master/HEAD and changed to always
return double.
On Thu, Dec 14, 2017 at 12:48 PM, Fabien COELHO wrote:
>
> Fixed in the attached patch.
>>
>
> v7 needs a rebase.
>
> Also, you might try to produce a version which is compatible with Robert's
> constraints
Fixed in the attached patch.
v7 needs a rebase.
Also, you might try to produce a version which is compatible with
Robert's constraints.
--
Fabien.
Raúl Marín Rodríguez wrote:
> I don't want to go too deep into it, but you get stuff like this:
>
> Select pow(2.0, -3)::text = pow(2, -3)::text;
> ?column?
> --
> f
Indeed, to me, that has turned out to be the most intriguing part of
the whole thread. Needs to be in some SQL subtletie
In both cases we'd return a double but we use the fast ipow if it's
possible (which can be 20x faster), so at the cost of an extra cast if
you need an int, we'd have a consistent API. Would this be acceptable?
It seems OK to me.
Computing as an int, casting to double and back to int8 can ge
On Tue, Dec 5, 2017 at 7:44 AM, Raúl Marín Rodríguez
wrote:
> I've been giving a thought about this and I think we could reach the
> compromise
> of having a single function with 2 overloads:
> * pow(double, double) -> double: Uses C pow().
> * pow(int, int) -> double: Uses ipow() for positive exp
I've been giving a thought about this and I think we could reach the
compromise
of having a single function with 2 overloads:
* pow(double, double) -> double: Uses C pow().
* pow(int, int) -> double: Uses ipow() for positive exponents, and pow()
for negative exponents.
In both cases we'd return
Hi all,
I've been giving a thought about this and I think we could reach the
compromise
of having a single function with 2 overloads:
* pow(double, double) -> double: Uses C pow().
* pow(int, int) -> double: Uses ipow() for positive exponents, and pow()
for negative exponents.
In both cases we'd
Hello Tom,
1. A patch that adds an integer version of pow() but not a double version
2. A patch that adds a double version of pow() but not an integer version
3. A patch that adds both an integer version of pow() and a double
version of pow(), with the two versions having different names
It
On Tue, Dec 5, 2017 at 11:32 AM, Tom Lane wrote:
> ISTM one key issue here is whether pgbench's expression language is
> meant to model SQL (where we have function overloading) or C (where
> there is no overloading). I don't think we've really settled on a
> fixed policy on that, but maybe now is
Michael Paquier writes:
> On Tue, Dec 5, 2017 at 5:38 AM, Robert Haas wrote:
>> I'm willing to commit any of the following things:
>>
>> 1. A patch that adds an integer version of pow() but not a double version
>> 2. A patch that adds a double version of pow() but not an integer version
>> 3. A
On Tue, Dec 5, 2017 at 5:38 AM, Robert Haas wrote:
> I'm willing to commit any of the following things:
>
> 1. A patch that adds an integer version of pow() but not a double version
> 2. A patch that adds a double version of pow() but not an integer version
> 3. A patch that adds both an integer v
On Mon, Dec 4, 2017 at 10:47 AM, Fabien COELHO wrote:
>> What's the name of the backend function whose behavior this matches?
>>
>> As Fabien has mentioned, it tries to behave as "numeric_power". Maybe we
>> it'd better if we switch to "dpow" (which is pow with some error handling)
>> and always r
Please add the new function into the documentation table in
alphabetical order.
Fixed in the attached patch.
Yep. Patch applies cleanly. Make check & pgbench check ok. make html ok.
POW is in the right place in the table, sorry I did not check before.
What's the name of the backend funct
Hi,
Please add the new function into the documentation table in alphabetical
> order.
Fixed in the attached patch.
What's the name of the backend function whose behavior this matches?
As Fabien has mentioned, it tries to behave as "numeric_power". Maybe we
it'd
better if we switch to "dpow" (w
The fact that the return type is not consistently of one type bothers
me. I'm not sure pgbench's expression language is a good place to
runtime polymorphism -- SQL doesn't work that way.
Sure.
Pg has a NUMERIC adaptative precision version, which is cheating, because it
can return kind of an
Hello Robert,
The fact that the return type is not consistently of one type bothers
me. I'm not sure pgbench's expression language is a good place to
runtime polymorphism -- SQL doesn't work that way.
Sure.
Pg has a NUMERIC adaptative precision version, which is cheating, because
it can re
On Fri, Dec 1, 2017 at 4:57 AM, Raúl Marín Rodríguez
wrote:
> I've rebased the patch so it can be applied cleanly on top of current
> master.
Please add the new function into the documentation table in alphabetical order.
The fact that the return type is not consistently of one type bothers
me.
Hi Fabien,
The idea is that it would be relative to the "more functions and operators"
> patch, but I guess this is too much for people checking, so I'm fine with
> having it with the current base.
>
I tried applying the last "more functions and operators" patch
(pgbench-more-ops-funcs-14.patch)
Hello Raúl,
I've rebased the patch so it can be applied cleanly on top of current
master.
The idea is that it would be relative to the "more functions and
operators" patch, but I guess this is too much for people checking, so I'm
fine with having it with the current base.
Patch applies cl
Hi,
I've rebased the patch so it can be applied cleanly on top of current
master.
On Fri, Dec 1, 2017 at 3:55 AM, Michael Paquier
wrote:
> On Tue, Nov 7, 2017 at 1:34 AM, Fabien COELHO wrote:
> > Let's now hope that a committer gets around to consider these patch some
> > day.
>
> Which is not
On Tue, Nov 7, 2017 at 1:34 AM, Fabien COELHO wrote:
> Let's now hope that a committer gets around to consider these patch some
> day.
Which is not the case yet, so moved to CF 2018-01. Please note that
the patch proposed does not apply anymore, so its status is changed to
"waiting on author" for
30 matches
Mail list logo
