RE: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode

From: Tom Lane <tgl@sss.pgh.pa.us>
> Possibly-crazy late-night idea ahead:
>
> IIUC, we need to know a global property of a partitioning hierarchy:
> is every trigger, CHECK constraint, etc that might be run by an INSERT
> parallel-safe?  What we see here is that reverse-engineering that
> property every time we need to know it is just too expensive, even
> with use of our available caching methods.
>
> How about a declarative approach instead?  That is, if a user would
> like parallelized inserts into a partitioned table, she must declare
> the table parallel-safe with some suitable annotation.  Then, checking
> the property during DML is next door to free, and instead we have to think
> about whether and how to enforce that the marking is valid during DDL.
>
> I don't honestly see a real cheap way to enforce such a property.
> For instance, if someone does ALTER FUNCTION to remove a function's
> parallel-safe marking, we can't really run around and verify that the
> function is not used in any CHECK constraint.  (Aside from the cost,
> there would be race conditions.)

I thought of a similar idea as below, which I was most reluctant to adopt.


https://www.postgresql.org/message-id/TYAPR01MB29907AE025B60A1C2CA5F08DFEA70%40TYAPR01MB2990.jpnprd01.prod.outlook.com
--------------------------------------------------
(3) Record the parallel safety in system catalog
Add a column like relparallel in pg_class that indicates the parallel safety of the relation.  planner just checks the
valueinstead of doing heavy work for every SQL statement.  That column's value is modified whenever a relation
alterationis made that affects the parallel safety, such as adding a domain column and CHECK constraint.  In case of a
partitionedrelation, the parallel safety attributes of all its descendant relations are merged.  For example, if a
partitionbecomes parallel-unsafe, the ascendant partitioned tables also become parallel-unsafe. 



But... developing such code would be burdonsome and bug-prone?
--------------------------------------------------


> But maybe we don't have to enforce it exactly.  It could be on the
> user's head that the marking is accurate.  We could prevent any
> really bad misbehavior by having parallel workers error out if they
> see they've been asked to execute a non-parallel-safe function.

I'm wondering if we can do so as I mentioned yesterday; the parallel worker delegates the work to the parallel leader
whenthe target relation or related functions is not parallel-safe. 


    Regards
Takayuki     Tsunakawa