> On Thu, Mar 11, 2021 at 01:01:42PM +0000, houzj.f...@fujitsu.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
