RE: Parallel INSERT (INTO ... SELECT ...)

> On Thu, Mar 11, 2021 at 01:01:42PM +0000, houzj(dot)fnst(at)fujitsu(dot)com wrote:
> > > I guess to have the finer granularity we'd have to go with
> > > enable_parallel_insert, which then would mean possibly having to
> > > later add enable_parallel_update, should parallel update have
> > > similar potential overhead in the parallel-safety checks (which to
> > > me, looks like it could, and parallel delete may not ...)
> > >
> > > It's a shame there is no "set" type for GUC options.
> > > e.g.
> > > enable_parallel_dml='insert,update'
> > > Maybe that's going too far.
>
> Isn't that just GUC_LIST_INPUT ?
> I'm not sure why it'd be going to far ?
>
> The GUC-setting assign hook can parse the enable_parallel_dml_list value set
> by the user, and set an internal int/bits enable_parallel_dml variable with some
> define/enum values like:
>
> GUC_PARALLEL_DML_INSERT 0x01
> GUC_PARALLEL_DML_DELETE 0x02
> GUC_PARALLEL_DML_UPDATE 0x04
>
> The namespace.c assign hook is a good prototype for this. The parsed,
> integer GUC can probably be a static variable in clauses.c.
>
> Then, the planner can check if:
> |commandType == CMD_INSERT &&
> | (enable_parallel_dml & GUC_PARALLEL_DML_INSERT) != 0
> [...]
>
> + this table. When enabled (and provided that
> + <xref linkend="guc-enable-parallel-insert"/> is also
> + <literal>true</literal>),

I think this ideas works, but we still need to consider about the reloption.
After looking into the reloption, I think postgres do not have a list-like type for reloption.
And I think it's better that the guc and reloption is consistent.

Besides, a list type guc option that only support one valid value 'insert' seems a little weird to me(we only support parallel insert for now).

So, I tend to keep the current style of guc option.
If we turn out that we do need same option to restrict update/delete, we can improve this in the future
What do you think ?

Best regards,
houzj