> I guess to have the finer granularity we'd have to go with > enable_parallel_insert, > which then would mean possibly having to later add enable_parallel_update, > should parallel update have similar potential overhead in the parallel-safety > checks (which to me, looks like it could, and parallel delete may not ...) > > It's a shame there is no "set" type for GUC options. > e.g. > enable_parallel_dml='insert,update' > Maybe that's going too far. > > > 2. Should we keep the default value of GUC to on or off? It is > > currently off. I am fine keeping it off for this release and we can > > always turn it on in the later releases if required. Having said that, > > I see the value in keeping it on because in many cases Insert ... > > Select will be used for large data and there we will see a benefit of > > parallelism and users facing trouble (who have a very large number of > > partitions with less data to query) can still disable the parallel > > insert for that particular table. Also, the other benefit of keeping > > it on till at least the beta period is that this functionality will > > get tested and if we found reports of regression then we can turn it > > off for this release as well. > > > > I'd agree to keeping it on by default (and it can be selectively turned off > for a > particular table using the reloption, if needed).
Thanks, attaching new version patch keeping the default value of guc option to ON. Best regards, houzj
v26-0003-Parallel-SELECT-for-INSERT-INTO-.-SELECT-advanced-tests.patch
Description: v26-0003-Parallel-SELECT-for-INSERT-INTO-.-SELECT-advanced-tests.patch
v26-0002-Add-new-GUC-option-enable_parallel_insert-boolean.patch
Description: v26-0002-Add-new-GUC-option-enable_parallel_insert-boolean.patch