On Fri, Oct 21, 2016 at 10:55 PM, Robert Haas <robertmh...@gmail.com> wrote: > 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? >
That makes sense to me. As of now, patch doesn't consider reloptions for parallel index scans. So, I think we can leave it as it is and then later as a separate patch decide whether to use reloption of table or a separate reloption for index would be better choice. -- 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
