On Thu, Oct 20, 2016 at 10:33 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Oct 19, 2016 at 11:07 PM, Amit Kapila <amit.kapil...@gmail.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. >
I think there is big difference of size of relation to scan between parallel sequential scan and parallel (range) index scan which could make it difficult for user to choose the value of this parameter. Why do you think that the parallel_workers reloption should suffice all type of scans for a table? I could only think of providing it based on thinking that lesser config knobs makes life easier. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
