From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Some optimisations for numeric division |
Date: | 2022-02-23 22:46:50 |
Message-ID: | CAEZATCW7mFUKrxxje4HKzMEfLgxgp4mPMEb1qTaMuZf8JuArKA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 23 Feb 2022 at 20:55, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-02-23 22:53:17 | Re: convert libpq uri-regress tests to tap test |
Previous Message | samay sharma | 2022-02-23 22:11:33 | Re: Proposal: Support custom authentication methods using hooks |