Re: Numeric multiplication overflow errors
Dean Rasheed <dean.a.rasheed@gmail.com>
From: Dean Rasheed <dean.a.rasheed@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-07-01T12:28:11Z
Lists: 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
Commits
-
Fix numeric_mul() overflow due to too many digits after decimal point.
- f8abf6944b12 9.6.23 landed
- 54a0ec1bd6d5 10.18 landed
- 5763ef42c187 11.13 landed
- 357b66ef9470 12.8 landed
- f23a9b8a49af 13.4 landed
- 06883d58ff29 14.0 landed
- e7fc488ad67c 15.0 landed
-
Prevent numeric overflows in parallel numeric aggregates.
- f025f2390e13 15.0 landed