On Thu, Jun 18, 2020 at 10:10 PM David Rowley <dgrowle...@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
