RE: Parallel INSERT SELECT take 2

From: Greg Nancarrow <gregn4422(at)gmail(dot)com>
> On Mon, May 31, 2021 at 3:34 PM houzj(dot)fnst(at)fujitsu(dot)com
> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> >
> >
> > Attaching v6 patchset.
> > And I registered it in CF https://commitfest.postgresql.org/33/3143/,
> > comments are welcome.
> >
>
> The latest patchset has some documentation updates. I'd like to suggest a
> couple of documentation tweaks (this is mainly just minor word changes and
> some extra details):
>
> (1)
> doc/src/sgml/ref/create_foreign_table.sgml
> doc/src/sgml/ref/create_table.sgml
>
> PARALLEL DML UNSAFE indicates that the data in the table can't be modified in
> parallel mode, and this forces a serial execution plan for DML statements
> operating on the table. This is the default. PARALLEL DML RESTRICTED
> indicates that the data in the table can be modified in parallel mode, but the
> modification is restricted to the parallel group leader. PARALLEL DML SAFE
> indicates that the data in the table can be modified in parallel mode without
> restriction. Note that PostgreSQL currently does not support data
> modification by parallel workers.
>
> Tables should be labeled parallel dml unsafe/restricted if any parallel
> unsafe/restricted function could be executed when modifying the data in the
> table (e.g., functions in triggers/index expressions/constraints etc.).
>
> To assist in correctly labeling the parallel DML safety level of a table,
> PostgreSQL provides some utility functions that may be used during
> application development. Refer to pg_get_parallel_safety() and
> pg_get_max_parallel_hazard() for more information.
>
>
> (2) doc/src/sgml/func.sgml
>
> (i) pg_get_parallel_safety
> Returns a row containing enough information to uniquely identify the 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 parallel DML fails or behaves unexpectedly. Note that
> when the use of an object-related parallel unsafe/restricted function is
> detected, both the function OID and the object OID are returned. classid is the
> OID of the system catalog containing the object; objid is the OID of the object
> itself.
>
> (ii) pg_get_max_parallel_hazard
> Returns the worst parallel DML safety hazard that can be found in the given
> relation:
> s safe
> r restricted
> u unsafe
> Users can use this function to do a quick check without caring about specific
> parallel-related objects.

Thanks for looking into the doc change, I think your change looks better and
have merged it in the attached patch.

> Also, shouldn't support for "Parallel" be added for table output in PSQL? (e.g.
> \dt+)

Yeah, I think we should add it and I added it in the attached 0001 patch.

Best regards,
houzj