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 20:55:12
Message-ID: 1250734.1645649712@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:
> Attached are 3 small patches that improve the performance of numeric
> division. Patch 0002 seems to have the biggest impact, but I think
> they're all worth including, since they're quite simple changes, with
> noticeable performance gains.

I took a quick look through these (just eyeball, didn't try to verify
your performance statements). 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?
Another idea is to only worry about the single-divisor-digit
optimization, and just copy div_var's (very small) inner loop for that
case into div_var_fast.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-02-23 20:57:08 Re: convert libpq uri-regress tests to tap test
Previous Message Daniel Gustafsson 2022-02-23 20:40:59 Re: convert libpq uri-regress tests to tap test