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 CANWCAZbtgOjT_vybYFPFu2jn8H-6zuXpb0uPBUjnyPvzkf6Q_g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Improving and extending int128.h to more of numeric.c  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Список pgsql-hackers
On Thu, Jul 17, 2025 at 1:24 AM Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
>
> On Wed, 16 Jul 2025 at 10:02, John Naylor <johncnaylorls@gmail.com> wrote:
>
> > Which queries were you testing?
>
> I used the following 2 queries:
>
> SELECT count(*), sum(x), avg(x)
>   FROM generate_series(1::bigint, 10000000::bigint) g(x);
>
> SELECT count(*), var_pop(x), var_samp(x), stddev_pop(x), stddev_samp(x)
>   FROM generate_series(1::int, 10000000::int) g(x);
>
> 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

While testing something else on s390x, I noticed that __int128 support
is broken on that platform at least for some versions of clang [1],
and I see improvement there with this patch:

Query 1:
HEAD:  3015ms
Patch: 2206ms

Query 2:
HEAD:  3394ms
Patch: 2514ms

> > (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.)
>
> Hmm, are you sure? I don't see that. With -m32, I see:
>
> select sum(i) from generate_series(1e10, 1e10+1e6, 1) i;
>   HEAD:  204.774 ms
>   Patch: 204.206 ms
> (not expecting any difference)
>
> select sum(i) from generate_series(10_000_000_000, 10_001_000_000, 1) i;
>   HEAD:  187.426 ms
>   Patch: 140.741 ms
> (as expected, faster than the previous query in HEAD because bigint
> generate_series should be faster than numeric generate_series, and
> faster still with the sum(bigint) optimisations made by this patch)

Hmm, at the time I was surprised too, and ran multiple times but today
I can't reproduce my earlier results, so not sure what happened. :/

[1] https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=treehopper&dt=2025-07-17%2019%3A26%3A04&stg=configure

--
John Naylor
Amazon Web Services



В списке pgsql-hackers по дате отправления: