From: | Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
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 14:28:30 |
Message-ID: | CAM6_UM5SCAicrDoHeQ1CcHc8D1M6vV-T-NQVZjYonjCETqw=pA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi Fabien,
Sorry for the confusion, I wasn't aware that SQL pow changed types
depending on
the input value.
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?
On Mon, Nov 6, 2017 at 2:12 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
>
> Hello Raúl,
>
> I've fixed the documentation and added an ipow function that handles both
>> positive and negative ints, having 0^0 == 1 and 0^(negative) ==
>> PG_INT64_MAX
>> since that's what my glibc math.h pow() is returning.
>>
>
> From the comment:
>
> * For exp < 0 return 0 except when the base is 1 or -1
>
> I think that it should do what POW does in psql, i.e.:
>
> fabien=# SELECT POW(2, -2); # 0.25
>
> that is if exp < 0 the double version should be used, it should
> not return 0.
>
> Basically the idea is that the pgbench client-side version should behave
> the same as the SQL version.
>
> --
> Fabien.
--
*Raúl Marín Rodríguez*carto.com
Attachment | Content-Type | Size |
---|---|---|
pgbench_pow_v4_pgbench-more-ops-funcs-14.patch | text/x-patch | 4.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2017-11-06 14:30:16 | Re: Early locking option to parallel backup |
Previous Message | Paul Ramsey | 2017-11-06 14:10:21 | Re: Parallel Plans and Cost of non-filter functions |