Re: [HACKERS] pow support for pgbench

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Raúl Marín Rodríguez <rmrodriguez(at)carto(dot)com>, 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-27 07:49:07
Message-ID: alpine.DEB.2.20.1712270840070.22976@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Bonjour Michaël,

> And my 2c on the matter is that switching silently from one version to
> the other would be unwelcome. The user should be aware if a test is
> overflowing a number when specifying an integer.

This whole integer pow version is becoming unduly complicated and ugly.

For me, the rational of having the ipow implementation was to have a
precise integer result when possible. Now that it is casted to double and
the precision is lost, the whole point of ipow is moot, even if there is
some performance gain.

So given that committers do not want the int/double version because it is
slightly different from the numeric/double version of SQL (obviously), and
that the integer version is becoming over complicated with checks and
warnings or errors, I'm now in favor of just dropping it, and provide the
double version only.

Too bad for integer computations on keys which is the core of pgbench use
case, but I can't help it.

--
Fabien.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-12-27 07:53:42 Re: Getting rid of "tuple concurrently updated" elog()s with concurrent DDLs (at least ALTER TABLE)
Previous Message Feike Steenbergen 2017-12-27 07:47:20 Re: Add hint about replication slots when nearing wraparound