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>),

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