Re: Parallel Index Scans
Peter Geoghegan <pg@heroku.com>
From: Peter Geoghegan <pg@heroku.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-10-20T03:24:53Z
Lists: pgsql-hackers
On Wed, Oct 19, 2016 at 8:07 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > I have also checked and found that you are right. In SQL Server, they > are using max degree of parallelism (MAXDOP) parameter which is I > think is common for all the sql statements. It's not just that one that does things this way, for what it's worth. > I can understand that it can be confusing to users, so other option > could be to provide separate parameters like parallel_workers_build > and parallel_workers where first can be used for index build and > second can be used for scan. My personal opinion is to have one > parameter, so that users have one less thing to learn about > parallelism. That's my first instinct too, but I don't really have an opinion yet. I think that this is the kind of thing where it could make sense to take a "wait and see" approach, and then make a firm decision immediately prior to beta. This is what we did in deciding the name of and fine details around what ultimately became the max_parallel_workers_per_gather GUC (plus related GUCs and storage parameters). -- Peter Geoghegan
Commits
-
Replace min_parallel_relation_size with two new GUCs.
- 51ee6f3160d2 10.0 landed
-
Factor out logic for computing number of parallel workers.
- 716c7d4b242f 10.0 cited
-
Support condition variables.
- e8ac886c2477 10.0 cited
-
Allow parallel custom and foreign scans.
- 69d34408e5e7 9.6.0 cited
-
Add a C API for parallel heap scans.
- ee7ca559fcf4 9.6.0 cited