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;
Sure. It does so with any overloaded operator or function:
fabien=# SELECT (2.0 + 3)::TEXT = (2 + 3)::TEXT; # f
Patch applies, make check ok in pgbench, doc gen ok.
ipow code i
Hi,
Indeed, this is quite strange...
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
(1 row)
- you can simplify the ipow function by removing handling of y<0 case,
>maybe add an assert to be sure to
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 matc
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,
Hi Fabien,
Thanks for the review.
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.
On Sat, Nov 4, 2017 at 12:34 PM, Fabien COELHO 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
Hello Raúl,
Sorry about the patch. Attaching it now so it can be considered as
submitted.
There is a typo in the XML doc:
1024.0/
Please check that the documentation compiles.
I'm at odds with having the integer version rely on a double pow(), even
if it works. I think that there
Hello Michaël,
I'm fine with having pow in pgbench.
I am adding as well Fabien in CC who worked in getting the internal
function infrastructure in the shape it is now (waaay better) with
commit 86c43f4.
It might be even better if https://commitfest.postgresql.org/15/985/,
which has been aro
Sorry about the patch. Attaching it now so it can be considered as
submitted.
--
*Raúl Marín Rodríguez*carto.com
From a6eecfe6637bdb0cbb02a9eda7b88d9c4325bb51 Mon Sep 17 00:00:00 2001
From: Raul Marin
Date: Fri, 13 Oct 2017 17:42:23 +0200
Subject: [PATCH] Add pow() support to pgbench
---
doc/
Hi,
both patches seem complementary. I've rebased my changes on top of that
patch
(v14) in https://git.io/vFtnT and everything seems to be working fine.
On Mon, Oct 30, 2017 at 12:36 PM, Michael Paquier wrote:
> On Mon, Oct 30, 2017 at 11:07 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrot
Michael Paquier wrote:
> Attaching patches directly to a thread is a better practice as if
> github goes away, any Postgres developers can still have an access to
> any code you publish using the public archives on postgresql.org.
Also, by posting to pgsql-hackers indicating intention to integrat
On Mon, Oct 30, 2017 at 11:56 AM, Raúl Marín Rodríguez
wrote:
> both patches seem complementary. I've rebased my changes on top of that
> patch
> (v14) in https://git.io/vFtnT and everything seems to be working fine.
Attaching patches directly to a thread is a better practice as if
github goes aw
On Mon, Oct 30, 2017 at 11:07 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> Please add this patch to the upcoming commit fest if you would like to
>> get some feedback:
>> https://commitfest.postgresql.org/15/
>>
>> I am adding as well Fabien in CC who worked in getting the internal
>> f
Michael Paquier wrote:
> Please add this patch to the upcoming commit fest if you would like to
> get some feedback:
> https://commitfest.postgresql.org/15/
>
> I am adding as well Fabien in CC who worked in getting the internal
> function infrastructure in the shape it is now (waaay better) with
On Fri, Oct 27, 2017 at 4:51 PM, Raúl Marín Rodríguez
wrote:
> I've written a small patch to add support for pow() in pgbench.
Cool.
> The main reason behind it is that I'm currently using a shell call to do it
> which takes between 2-10 ms that can be a big percentage of the time taken
> by the
Hi,
I've written a small patch to add support for pow() in pgbench.
The main reason behind it is that I'm currently using a shell call to do it
which takes between 2-10 ms that can be a big percentage of the time taken
by the whole transaction. For example (shortened):
latency average = 11.718 m
16 matches
Mail list logo
