Re: Parallel Seq Scan vs kernel read ahead
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>, Ranier Vilela <ranier.vf@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-19T20:00:07Z
Lists: pgsql-hackers
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
Commits
-
Allocate consecutive blocks during parallel seqscans
- 56788d2156fc 14.0 landed