From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)heroku(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parallel Index Scans |
Date: | 2016-10-20 17:03:24 |
Message-ID: | CA+TgmoZ+4APr++_TA=hk8UKNE_4A2g4Fds3aVbY=9eBsCLv5ZA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Oct 19, 2016 at 11:07 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> Ideally, the parallel_workers storage parameter will rarely be
>> necessary because the optimizer will generally do the right thing in
>> all case.
>
> Yeah, we can choose not to provide any parameter for parallel index
> scans, but some users might want to have a parameter similar to
> parallel table scans, so it could be handy for them to use.
I think the parallel_workers reloption should override the degree of
parallelism for any sort of parallel scan on that table. Had I
intended it to apply only to sequential scans, I would have named it
differently.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2016-10-20 17:14:28 | Re: LLVM Address Sanitizer (ASAN) and valgrind support |
Previous Message | Robert Haas | 2016-10-20 16:58:38 | Re: Remove autovacuum GUC? |