On Thu, Jun 18, 2020 at 10:10 PM David Rowley <dgrowleyml@gmail.com> wrote:
> Here's a patch which caps the maximum chunk size to 131072. If
> someone doubles the page size then that'll be 2GB instead of 1GB. I'm
> not personally worried about that.
Maybe use RELSEG_SIZE?
> I tested the performance on a Windows 10 laptop using the test case from [1]
>
> Master:
>
> workers=0: Time: 141175.935 ms (02:21.176)
> workers=1: Time: 316854.538 ms (05:16.855)
> workers=2: Time: 323471.791 ms (05:23.472)
> workers=3: Time: 321637.945 ms (05:21.638)
> workers=4: Time: 308689.599 ms (05:08.690)
> workers=5: Time: 289014.709 ms (04:49.015)
> workers=6: Time: 267785.270 ms (04:27.785)
> workers=7: Time: 248735.817 ms (04:08.736)
>
> Patched:
>
> workers=0: Time: 155985.204 ms (02:35.985)
> workers=1: Time: 112238.741 ms (01:52.239)
> workers=2: Time: 105861.813 ms (01:45.862)
> workers=3: Time: 91874.311 ms (01:31.874)
> workers=4: Time: 92538.646 ms (01:32.539)
> workers=5: Time: 93012.902 ms (01:33.013)
> workers=6: Time: 94269.076 ms (01:34.269)
> workers=7: Time: 90858.458 ms (01:30.858)
Nice results. I wonder if these stack with the gains Thomas was
discussing with his DSM-from-the-main-shmem-segment patch.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
