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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 value instead of doing heavy work for every SQL statement. That column's value is modified whenever a relation alteration is made that affects the parallel safety, such as adding a domain column and CHECK constraint. In case of a partitioned relation, the parallel safety attributes of all its descendant relations are merged. For example, if a partition becomes 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 when the target relation or related functions is not parallel-safe.

Regards
Takayuki Tsunakawa