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

From Dean Rasheed
Subject Re: Numeric multiplication overflow errors
Date
Msg-id CAEZATCV2cisoKhGkbCyUGsfgBN66SVXocqbv6DpF9vCBs2QoxA@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 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: wrong relkind error messages
Next
From: Ranier Vilela
Date:
Subject: Re: Signed vs. Unsigned (some)