Re: [HACKERS] pow support for pgbench

From: Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] pow support for pgbench
Date: 2017-12-04 10:06:07
Message-ID: CAM6_UM41nbU4oPcQ72AM0gEf7OtvasrKbSUeb2VnEN8FVUc8wg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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" (which is pow with some error handling) and
always
return a double. What do you think?

On Fri, Dec 1, 2017 at 8:02 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Dec 1, 2017 at 4:57 AM, Raúl Marín Rodríguez
> <rmrodriguez(at)carto(dot)com> 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. I'm not sure pgbench's expression language is a good place to
> runtime polymorphism -- SQL doesn't work that way.
>
> + /*
> + * pow() for integer values with exp >= 0. Matches SQL pow() behaviour
> + */
>
> What's the name of the backend function whose behavior this matches?
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

--

*Raúl Marín Rodríguez *carto.com

Attachment Content-Type Size
pgbench_pow_v7.patch text/x-patch 5.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Glapa 2017-12-04 12:18:38 Re: ERROR: too many dynamic shared memory segments
Previous Message John Naylor 2017-12-04 10:03:27 WIP: a way forward on bootstrap data