Re: Determine parallel-safety of partition relations for Inserts

On Fri, Jan 29, 2021 at 5:44 PM Hou, Zhijie <houzj.fnst@cn.fujitsu.com> wrote:
>
>
> Attatching v1 patches, introducing options which let user manually control whether to use parallel dml.
>
> About the patch:
> 1. add a new guc option: enable_parallel_dml (boolean)
> 2. add a new tableoption: parallel_dml (boolean)
>
>    The default of both is off(false).
>
> User can set enable_parallel_dml in postgresql.conf or seesion to enable parallel dml.
> If user want to choose some specific to use parallel insert, they can set table.parallel_dml to on.
>
> Some attention：
> (1)
> Currently if guc option enable_parallel_dml is set to on but table's parallel_dml is off,
> planner still do not consider parallel for dml.
>
> In this way, If user want to use parallel dml , they have to set enable_parallel_dml=on and set parallel_dml = on.
> If someone dislike this, I think we can also let tableoption. parallel_dml's default value to on ,with this user only
need
> to set enable_parallel_dml=on
>
> (2)
> For the parallel_dml.
> If target table is partitioned, and it's parallel_dml is set to on, planner will ignore
> The option value of it's child.
> This is beacause we can not divide dml plan to separate table, so we just check the target table itself.
>
>
> Thoughts and comments are welcome.
>

Personally, I think a table's "parallel_dml" option should be ON by default.
It's annoying to have to separately enable it for each and every table
being used, when I think the need to turn it selectively OFF should be
fairly rare.
And I'm not sure that "parallel_dml" is the best name for the table
option - because it sort of implies parallel dml WILL be used - but
that isn't true, it depends on other factors too.
So I think (to be consistent with other table option naming) it would
have to be something like "parallel_dml_enabled".
I'm still looking at the patches, but have so far noticed that there
are some issues in the documentation updates (grammatical issues and
consistency issues with current documentation), and also some of the
explanations are not clear. I guess I can address these separately.

Regards,
Greg Nancarrow
Fujitsu Australia