Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Raúl Marín Rodríguez
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

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Raúl Marín Rodríguez
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,

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Raúl Marín Rodríguez
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

Re: [HACKERS] pow support for pgbench

2017-11-06 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-11-04 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Fabien COELHO
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

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Raúl Marín Rodríguez
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()

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Raúl Marín Rodríguez
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 >

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Alvaro Herrera
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

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Michael Paquier
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

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Michael Paquier
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

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Alvaro Herrera
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)

Re: [HACKERS] pow support for pgbench

2017-10-30 Thread Michael Paquier
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

[HACKERS] pow support for pgbench

2017-10-30 Thread Raúl Marín Rodríguez
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