From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | John Naylor <johncnaylorls(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improving and extending int128.h to more of numeric.c |
Date: | 2025-07-17 07:29:53 |
Message-ID: | CAEZATCXnRaQG7xwm=_4+T3ZhMxb30ispKu8k8nmCQa++mD6Ofg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 16 Jul 2025 at 19:23, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>
> On 64-bit Linux with gcc 14.2 and native int128 support disabled I got
> the following results:
>
> Query 1:
> HEAD: 1404.096 ms
> Patch: 992.818 ms
>
> Query 2:
> HEAD: 1498.949 ms
> Patch: 935.654 ms
>
BTW, my other motivation for doing this was to simplify the numeric
code. Even if this had zero performance benefit, as long as it didn't
make things any slower, I would argue that it's worth doing.
The other 2 places in numeric.c that have conditional 128-bit integer
code would require more complex hand-written code to replace, such as
128-bit-by-128-bit division. That's obviously doable, but perhaps not
worth the effort as long as it's only those 2 numeric functions that
need it. OTOH, if there's a wider demand for 128-bit integers, that
might change.
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2025-07-17 07:43:20 | Re: Optimize LISTEN/NOTIFY |
Previous Message | Michael Paquier | 2025-07-17 06:42:11 | Re: Missing NULL check after calling ecpg_strdup |