Re: Some optimisations for numeric division

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Some optimisations for numeric division
Date: 2022-02-23 22:55:02
Message-ID: 1261055.1645656902@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> On Wed, 23 Feb 2022 at 20:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm +1 on 0001 and 0002, but 0003 feels
>> a bit ad-hoc. It certainly *looks* weird for the allegedly faster
>> function to be handing off to the allegedly slower one. I also wonder
>> if we're leaving anything on the table by not exploiting
>> div_var_fast's weaker roundoff guarantees in this case. Should we
>> think about a more thoroughgoing redesign of these functions' APIs?

> Hmm, I'm not sure what kind of thing you had in mind.

I'm not either, tbh. Just seems like this needs more than some
hacking around the margins.

> One thought that occurred to me was that it's a bit silly that
> exp_var() and ln_var() have to use a NumericVar for what could just be
> an int, if we had a div_var_int() function that could divide by an
> int. Then both div_var() and div_var_fast() could hand off to it for
> one and two digit divisors.

Oooh, that seems like a good idea.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-02-23 22:58:37 Re: convert libpq uri-regress tests to tap test
Previous Message Peter Eisentraut 2022-02-23 22:53:17 Re: convert libpq uri-regress tests to tap test