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>), It seems like this usefully allows the GUC to be enabled, and reloption to be disabled. But if the GUC is disabled, then it's impossible to enable for a single table. That seems unfortunate. I think part of the issue is the naming. If the GUC is called "enable_*", then setting it to "off" should disable it entirely, for consistency with other GUCs. So maybe it needs another name, like parallel_dml='insert'. I think maybe "all" should be an accepted value. Note also this CF entry https://commitfest.postgresql.org/32/2987/ | Allow setting parallel_workers on partitioned tables -- Justin
