From: Amit Kapila <[email protected]>
> 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. That is, it'd be very rare that child
partitions have different indexes, constraints, and triggers. So, we can just
check the 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 partition turns 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
