Re: Choosing parallel_degree
От | Robert Haas |
---|---|
Тема | Re: Choosing parallel_degree |
Дата | |
Msg-id | CA+TgmoYStC=n-QrVzaJwYQJzO6XJNZNoOq6YRA1bTZLVPH6Nmg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Choosing parallel_degree (Julien Rouhaud <julien.rouhaud@dalibo.com>) |
Ответы |
Re: Choosing parallel_degree
Re: Choosing parallel_degree |
Список | pgsql-hackers |
On Wed, Mar 16, 2016 at 1:23 PM, Julien Rouhaud <julien.rouhaud@dalibo.com> wrote: > On 16/03/2016 17:55, Robert Haas wrote: >> On Wed, Mar 16, 2016 at 12:47 PM, Julien Rouhaud >> <julien.rouhaud@dalibo.com> wrote: >>> Something like a "min_parallel_degree" then ? >> >> Why not just parallel_degree without any prefix? As in, when scanning >> this table in parallel, the reloption suggests using N workers. >> > > Agreed. > > PFA v2 that implements that. I think create_parallel_paths shouldn't actually run the loop if the reloption is specified; it should just adopt the specified value (or max_parallel_degree, whichever is less). Right now, you have it doing the work to compute the default value but then overriding it. Also, I think parallel_degree should be down in the section that says /* information about a base rel (not set for join rels!) */ and I think it should be called something like rel_parallel_degree, to make it more clear that it's a value set on the relation level. Let's leave out the parallel_threshold stuff for now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: