From: Amit Kapila <amit.kapila16@gmail.com>
> Okay, I can revert this work to avoid that risk but it would be great
> if you can share your thoughts on what alternative design do you have
> in mind, and or how it should be better implemented? Regarding
> performance overhead, it is for partitioned tables with a large number
> of partitions, and that too when the data to insert is not that much
> or there is parallel-unsafe clause on one of the partitions. Now, how
> else can we determine the parallel-safety without checking each of the
> partitions? We do have other partition-related gucs
> (enable_partition*) to avoid the partitions-related overhead so why is
> it so bad to have guc here (maybe the naming of guc/reloption is not
> good)?
>
I'd love to hear even rough ideas from Robert-san. I guess something like...:
* Basically, we can assume or hope that all partitions have the same parallel safety as the root partitioned table.
Thatis, it'd be very rare that child partitions have different indexes, constraints, and triggers. So, we can just
checkthe root table during planning to decide if we want to run parallel processing.
* When the executor opens a target child partition, it checks its parallel safety only once for it. If any target
partitionturns out to be parallel unsafe, have the parallel leader do the insertion shomehow.
TBH, I don't think the parameter is so ugly. At least, it's not worse than Oracle or SQL Server.
Regards
Takayuki Tsunakawa
