Re: Some optimisations for numeric division - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Some optimisations for numeric division
Date
Msg-id CAEZATCW7mFUKrxxje4HKzMEfLgxgp4mPMEb1qTaMuZf8JuArKA@mail.gmail.com
Whole thread Raw
In response to Re: Some optimisations for numeric division  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Some optimisations for numeric division  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, 23 Feb 2022 at 20:55, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I took a quick look through these (just eyeball, didn't try to verify
> your performance statements).

Thanks for looking!

>  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.

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.

Regards,
Dean



pgsql-hackers by date:

Previous
From: samay sharma
Date:
Subject: Re: Proposal: Support custom authentication methods using hooks
Next
From: Peter Eisentraut
Date:
Subject: Re: convert libpq uri-regress tests to tap test