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:

Reply via email to