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 по дате отправления: