Re: Numeric multiplication overflow errors - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Numeric multiplication overflow errors
Date
Msg-id CAEZATCXV3TO1Qm01gMeNZyf1utyHEJ=TsPu3wM+6GMcsDM0-_Q@mail.gmail.com
Whole thread Raw
In response to Re: Numeric multiplication overflow errors  (David Rowley <dgrowleyml@gmail.com>)
Responses Re: Numeric multiplication overflow errors  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
On Thu, 1 Jul 2021 at 06:43, David Rowley <dgrowleyml@gmail.com> wrote:
>
> Master @ 3788c6678
>
> Execution Time: 8306.319 ms
> Execution Time: 8407.785 ms
> Execution Time: 8491.056 ms
>
> Master + numeric-agg-sumX2-overflow-v2.patch
> Execution Time: 6633.278 ms
> Execution Time: 6657.350 ms
> Execution Time: 6568.184 ms
>

Hmm, I'm a bit surprised by those numbers. I wouldn't have expected it
to be spending enough time in the serialization/deserialization code
for it to make such a difference. I was only able to measure a 2-3%
performance improvement with the same test, and that was barely above
the noise.

> A possible reason we might not want to do this is that we currently
> don't have a NumericSumAccum for some functions when the compiler has
> a working int128 type.  At the moment we translate the int128
> accumulator into a NumericVar. We could just serialize the int128 type
> in those cases. It would just mean the serialised format is not as
> consistent between different builds. We currently have nothing that
> depends on them matching across different machines.
>
> Do you think it's worth doing this?
>

I think it's probably not worth doing this. I remain sceptical that it
could give that much of a performance gain, and keeping the
platform-independent state might well be useful in the future.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Added schema level support for publication.
Next
From: Fujii Masao
Date:
Subject: Re: postgres_fdw - should we tighten up batch_size, fetch_size options against non-numeric values?