On 16/03/2016 05:45, James Sewell wrote: > On Wed, Mar 16, 2016 at 11:26 AM, Julien Rouhaud > <julien.rouh...@dalibo.com <mailto:julien.rouh...@dalibo.com>>wrote: > > > I'm not too familiar with parallel planning, but I tried to implement > both in attached patch. I didn't put much effort into the > parallel_threshold GUC documentation, because I didn't really see a good > way to explain it. I'd e happy to improve it if needed. Also, to make > this parameter easier to tune for users, perhaps we could divide the > default value by 3 and use it as is in the first iteration in > create_parallel_path() ? > > Also, global max_parallel_degree still needs to be at least 1 for the > per table value to be considered. > > > All applies and works from my end. >
Thanks for testing! > Is the max_parallel_degree per table of much use here? It allows the max > number of workers per table to be set - but it's still bound by the same > formula (now from the GUC). So in reality it's only really useful for > limiting the number of workers, not raising it. > You can set a global max_parallel_degree low, and raise it per table. If you set up max_parallel_degree to 1, you can "activate" parallel workers for only a subset of tables. -- Julien Rouhaud http://dalibo.com - http://dalibo.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
