On Fri, Oct 21, 2016 at 9:27 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> 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.
Well, we could do that, but it would be fairly complicated and it doesn't seem to me to be the right place to focus our efforts. I'd rather try to figure out some way to make the planner smarter, because even if users can override the number of workers on a per-table-per-scan-type basis, they're probably still going to find using parallel query pretty frustrating unless we make the number-of-workers formula smarter than it is today. Anyway, even if we do decide to add more reloptions than just parallel_degree someday, couldn't that be left for a separate patch? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers