RE: Determine parallel-safety of partition relations for Inserts - Mailing list pgsql-hackers

From Hou, Zhijie
Subject RE: Determine parallel-safety of partition relations for Inserts
Date
Msg-id 7da04d9f3a674268898c64515ba7424c@G08CNEXMBPEKD05.g08.fujitsu.local
Whole thread Raw
In response to Determine parallel-safety of partition relations for Inserts  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Determine parallel-safety of partition relations for Inserts  (Greg Nancarrow <gregn4422@gmail.com>)
List pgsql-hackers
Hi,

Attatching v1 patches, introducing options which let user manually control whether to use parallel dml.

About the patch:
1. add a new guc option: enable_parallel_dml (boolean)
2. add a new tableoption: parallel_dml (boolean)

   The default of both is off(false).

User can set enable_parallel_dml in postgresql.conf or seesion to enable parallel dml.
If user want to choose some specific to use parallel insert, they can set table.parallel_dml to on.

Some attention:
(1)
Currently if guc option enable_parallel_dml is set to on but table's parallel_dml is off,
planner still do not consider parallel for dml.

In this way, If user want to use parallel dml , they have to set enable_parallel_dml=on and set parallel_dml = on.
If someone dislike this, I think we can also let tableoption. parallel_dml's default value to on ,with this user only
need
to set enable_parallel_dml=on

(2)
For the parallel_dml.
If target table is partitioned, and it's parallel_dml is set to on, planner will ignore
The option value of it's child. 
This is beacause we can not divide dml plan to separate table, so we just check the target table itself.


Thoughts and comments are welcome.

Best regards,
houzj



Attachment

pgsql-hackers by date:

Previous
From: "Joel Jacobson"
Date:
Subject: Re: Add primary keys to system catalogs
Next
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit