Re: Parallel INSERT SELECT take 2 - Mailing list pgsql-hackers

From Greg Nancarrow
Subject Re: Parallel INSERT SELECT take 2
Date
Msg-id CAJcOf-dba19uOP+E6_Eh0o5-Wk4aLSQG5JRWwueJbK1V6JGcKw@mail.gmail.com
Whole thread Raw
In response to RE: Parallel INSERT SELECT take 2  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Responses RE: Parallel INSERT SELECT take 2
List pgsql-hackers
On Mon, May 31, 2021 at 3:34 PM houzj.fnst@fujitsu.com
<houzj.fnst@fujitsu.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.

 ---

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


Regards,
Greg Nancarrow
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side