RE: Parallel INSERT SELECT take 2

From: Greg Nancarrow <gregn4422(at)gmail(dot)com>
Sent: Wednesday, May 19, 2021 7:55 PM
>
> On Fri, May 14, 2021 at 6:24 PM houzj(dot)fnst(at)fujitsu(dot)com
> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> >
> > Thanks for the comments, I have posted new version patches with this
> change.
> >
> > > How about reorganisation of the patches like the following?
> > > 0001: CREATE ALTER TABLE PARALLEL DML
> > > 0002: parallel-SELECT-for-INSERT (planner changes,
> > > max_parallel_hazard() update, XID changes)
> > > 0003: pg_get_parallel_safety()
> > > 0004: regression test updates
> >
> > Thanks, it looks good and I reorganized the latest patchset in this way.
> >
> > Attaching new version patches with the following change.
> >
> > 0003
> > Change functions arg type to regclass.
> >
> > 0004
> > remove updates for "serial_schedule".
> >
>
> I've got some comments for the V4 set of patches:
>
> (0001)
>
> (i) Patch comment needs a little updating (suggested change is below):
>
> Enable users to declare a table's parallel data-modification safety
> (SAFE/RESTRICTED/UNSAFE).
>
> Add a table property that represents parallel safety of a table for
> DML statement execution.
> It may be specified as follows:
>
> CREATE TABLE table_name PARALLEL DML { UNSAFE | RESTRICTED | SAFE };
> ALTER TABLE table_name PARALLEL DML { UNSAFE | RESTRICTED | SAFE };
>
> This property is recorded in pg_class's relparallel column as 'u',
> 'r', or 's', just like pg_proc's proparallel.
> The default is UNSAFE.
>
> The planner assumes that all of the table, its descendant partitions,
> and their ancillary objects have,
> at worst, the specified parallel safety. The user is responsible for
> its correctness.
>
> ---
>
> NOTE: The following sentence was removed from the original V4 0001
> patch comment (since this version of the patch is not doing runtime
> parallel-safety checks on functions):.
>
> If the parallel processes
> find an object that is less safer than the assumed parallel safety during
> statement execution, it throws an ERROR and abort the statement execution.
>
>
> (ii) Update message to say "a foreign ...":
>
> BEFORE:
> + errmsg("cannot support parallel data modification on foreign or
> temporary table")));
>
> AFTER:
> + errmsg("cannot support parallel data modification on a foreign or
> temporary table")));
>
>
> (iii) strVal() macro already casts to "Value *", so the cast can be
> removed from the following:
>
> + char *parallel = strVal((Value *) def);
>
>
> (0003)
>
> (i) Suggested updates to the patch comment:
>
> Provide a utility function "pg_get_parallel_safety(regclass)" that
> returns records of
> (objid, classid, parallel_safety) for all parallel unsafe/restricted
> table-related objects
> from which the table's parallel DML safety is determined. The user can
> use this information
> during development in order to accurately declare a table's parallel
> DML safety. or to
> identify any problematic objects if a parallel DML fails or behaves
> unexpectedly.
>
> When the use of an index-related parallel unsafe/restricted function
> is detected, both the
> function oid and the index oid are returned.
>
> Provide a utility function "pg_get_max_parallel_hazard(regclass)" that
> returns the worst
> parallel DML safety hazard that can be found in the given relation.
> Users can use this
> function to do a quick check without caring about specific
> parallel-related objects.

Thanks for the comments and your descriptions looks good.
Attaching v5 patchset with all these changes.

Best regards,
houzj