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

From houzj.fnst@fujitsu.com
Subject RE: Parallel INSERT SELECT take 2
Date
Msg-id OS0PR01MB5716A0FE2EA8E3F8545B3FAF943D9@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Parallel INSERT SELECT take 2  (Greg Nancarrow <gregn4422@gmail.com>)
Responses RE: Parallel INSERT SELECT take 2
List pgsql-hackers
From: Greg Nancarrow <gregn4422@gmail.com>
> 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.

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

Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: security_definer_search_path GUC
Next
From: Andrey Lepikhov
Date:
Subject: Re: join pushdown and issue with foreign update