On Thu, Jul 17, 2025 at 2:30 PM Dean Rasheed wrote:
>
> 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.
I gathered that was the main motivatio
On Thu, Jul 17, 2025 at 1:24 AM Dean Rasheed wrote:
>
> On Wed, 16 Jul 2025 at 10:02, John Naylor wrote:
>
> > Which queries were you testing?
>
> I used the following 2 queries:
>
> SELECT count(*), sum(x), avg(x)
> FROM generate_series(1::bigint, 1000::bigint) g(x);
>
> SELECT count(*), v
On Wed, 16 Jul 2025 at 19:23, Dean Rasheed 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 fo
On Wed, 16 Jul 2025 at 10:02, John Naylor wrote:
>
> On Mon, Jun 23, 2025 at 3:01 PM Dean Rasheed 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 uncondit
On Tue, Jul 15, 2025 at 4:07 AM Dean Rasheed 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
Hi,
On 2025-07-14 22:07:38 +0100, Dean Rasheed wrote:
> (The cfbot reports the same warnings, but you have to scroll through a
> lot of output to see them. It would be nice if the commitfest app had
> an indicator to show if there were any compiler warnings.)
FWIW, for many warnings the CompilerW
On Mon, 14 Jul 2025 at 22:07, Dean Rasheed wrote:
>
> > warning: format ‘%lX’ expects argument of type ‘long unsigned int’,
> > but argument 4 has type ‘int32’ {aka ‘int’} [-Wformat=]
> >
> v4 attached.
v5 attached, fixing some more printf-related compiler warnings, this
time from the original te
On Mon, 14 Jul 2025 at 11:22, John Naylor wrote:
>
> (Looking at v3) The new test module runs 10 million rather than a
> billion iterations. That still takes 1.2s (after 0005), which seems
> excessive for regular buildfarm testing. It seems like we could get by
> with fewer than that, by using the
On Thu, Jul 10, 2025 at 9:06 PM Dean Rasheed wrote:
>
> On Wed, 9 Jul 2025 at 22:31, Dean Rasheed wrote:
> >
> > On Wed, 9 Jul 2025 at 18:27, Andres Freund wrote:
> > >
> > > I think we should wire this up to the buildsystem and our testsuite...
> > > Having
> > > testcode that is not run auto
On Thu, 10 Jul 2025 at 15:06, Dean Rasheed wrote:
>
> > Yes, perhaps we should convert src/tools/testint128.c into a new test
> > extension, src/test/modules/test_int128
>
> Here's an update doing that (in 0001). 0002-0005 are unchanged.
v3 attached, fixing a couple of issues revealed by the cfbo
On Wed, 9 Jul 2025 at 22:31, Dean Rasheed wrote:
>
> On Wed, 9 Jul 2025 at 18:27, Andres Freund wrote:
> >
> > I think we should wire this up to the buildsystem and our testsuite...
> > Having
> > testcode that is not run automatically may be helpful while originally
> > developing something, b
On Wed, 9 Jul 2025 at 18:27, Andres Freund wrote:
>
> I think we should wire this up to the buildsystem and our testsuite... Having
> testcode that is not run automatically may be helpful while originally
> developing something, but it doesn't do anything to detect portability issues
> or regress
Hi,
On 2025-07-09 10:38:31 +0100, Dean Rasheed wrote:
> On Wed, 9 Jul 2025 at 07:41, John Naylor wrote:
> >
> > Hi Dean, I went to take a look at this and got stuck at building the
> > test file. The usual pointing gcc to the src and build include
> > directories didn't cut it. How did you get it
On Wed, 9 Jul 2025 at 07:41, John Naylor wrote:
>
> Hi Dean, I went to take a look at this and got stuck at building the
> test file. The usual pointing gcc to the src and build include
> directories didn't cut it. How did you get it to work?
>
Yes, it wasn't immediately obvious how to do it. I f
On Mon, Jun 23, 2025 at 3:01 PM Dean Rasheed wrote:
> 0001 is a trivial bug fix for the test code in src/tools/testint128.c
> -- it was using "union" instead of "struct" for test128.hl, which
> meant that it was only ever setting and checking half of each 128-bit
> integer in the tests.
Hi Dean,
15 matches
Mail list logo
