From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pow support for pgbench |
Date: | 2017-11-06 15:14:11 |
Message-ID: | alpine.DEB.2.20.1711061551450.5606@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello,
> Sorry for the confusion, I wasn't aware that SQL pow changed types
> depending on the input value.
Indeed, this is quite strange...
fabien=# SELECT i, POW(2, i) FROM generate_series(-2, 2) AS i;
-2 | 0.25
-1 | 0.5
0 | 1
1 | 2
2 | 4
> I've modified the function to match more closely the behaviour of SQL,
> except that 0^(negative) returns 'double inf'. Do you think there is any
> value in raising an error instead?
fabien=# SELECT POW(0,-1);
ERROR: zero raised to a negative power is undefined
Hmmmm... I'm fine with double inf, because exception in pgbench means the
end of the script, which is not desirable for benchmarking purposes.
I think that:
- you can simplify the ipow function by removing handling of y<0 case,
maybe add an assert to be sure to avoid it.
- you should add more symmetry and simplify the evaluation:
if (int & int)
{
i1, i2 = ...;
if (i2 >= 0)
setIntValue(retval, ipow(i1, i2));
else
// conversion is done by C, no need to coerce again
setDoubleValue(retval, pow(i1, i2));
}
else
{
d1, d2 = ...;
setDoubleValue(retval, pow(d1, d2));
}
Add a test case to show what happens on NULL arguments, hopefully the
result is NULL.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Van Fleet | 2017-11-06 15:30:49 | Re: [POC] Faster processing at Gather node |
Previous Message | Sokolov Yura | 2017-11-06 15:07:14 | Re: Fix performance degradation of contended LWLock on NUMA |