From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Index Scans |
Date: | 2016-10-20 03:24:53 |
Message-ID: | CAM3SWZSUisNatz9-ZGc_nFey8fmuCW48kfcVXB5voemArSRb_w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 19, 2016 at 8:07 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-10-20 03:26:40 | Re: Avoiding pin scan during btree vacuum |
Previous Message | Amit Kapila | 2016-10-20 03:07:45 | Re: Parallel Index Scans |