Re: Improving and extending int128.h to more of numeric.c
От | John Naylor |
---|---|
Тема | Re: Improving and extending int128.h to more of numeric.c |
Дата | |
Msg-id | CANWCAZZVkLP0jF3bWGOt-boikafgBkh0n4iWdXNP4OuVLP3gLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Improving and extending int128.h to more of numeric.c (Dean Rasheed <dean.a.rasheed@gmail.com>) |
Ответы |
Re: Improving and extending int128.h to more of numeric.c
|
Список | pgsql-hackers |
On Tue, Jul 15, 2025 at 4:07 AM Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > > I have reduced the number of iterations and changed it to use the > current time for the PRNG seed. I don't see much value in logging the > seed though, since we already log the inputs that cause any failure. Ah, right. On Mon, Jun 23, 2025 at 3:01 PM Dean Rasheed <dean.a.rasheed@gmail.com> wrote: > 0005 is the main patch. It adds a few more functions to int128.h and > uses them in numeric.c to allow various functions (mainly aggregate > functions) to use 128-bit integers unconditionally on all platforms. > This applies to the following aggregates: > > - sum(int8) > - avg(int8) > - stddev_pop(int4) > - stddev_samp(int4) > - var_pop(int4) > - var_samp(int4) > Testing on a 32-bit system without native int128 support, I see > something like a 1.3-1.5x speedup in a couple of simple queries using > those aggregates. With v5, I don't see any difference from master when building on x86 with -m32 for these queries: select sum(i) from generate_series(1e10, 1e10+1e6, 1) i; select var_pop(i) from generate_series(1e9, 1e9+1e6, 1) i; Which queries were you testing? (Also, unrelated to the patch set, but I was surprised to find replacing the numeric expressions above with bigint ones (10_000_000_000 etc) makes the queries at least 5 times slower, and that's true with a normal 64-bit build as well.) -- John Naylor Amazon Web Services
В списке pgsql-hackers по дате отправления: