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-02T10:55:47Z
Lists: pgsql-hackers

Attachments

On Fri, 2 Jul 2021 at 10:24, David Rowley <dgrowleyml@gmail.com> wrote:
>
> I ran this again with a few different worker counts after tuning a few
> memory settings so there was no spilling to disk and so everything was
> in RAM. Mostly so I could get consistent results.
>
> Here's the results. Average over 3 runs on each:
>
> Workers Master Patched Percent
> 8            11094.1 11084.9 100.08%
> 16           8711.4  8562.6   101.74%
> 32           6961.4  6726.3  103.50%
> 64           6137.4  5854.8  104.83%
> 128         6090.3  5747.4  105.96%
>

Thanks for testing again. Those are nice looking results, and are much
more in line with what I was seeing.

> So the gains are much less at lower worker counts.  I think this is
> because most of the gains are in the serial part of the plan and with
> higher worker counts that part of the plan is relatively much bigger.
>
> So likely performance isn't too critical here, but it is something to
> keep in mind.
>

Yes, agreed. I suspect there's not much more that can be shaved off
this particular piece of code now though. Here's an update with the
last set of changes discussed.

Regards,
Dean

Commits

  1. Fix numeric_mul() overflow due to too many digits after decimal point.

  2. Prevent numeric overflows in parallel numeric aggregates.