On Wed, Mar 10, 2021 at 8:18 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > Now, coming back to Hou-San's patch to introduce a GUC and reloption > for this feature, I think both of those make sense to me because when > the feature is enabled via GUC, one might want to disable it for > partitioned tables? Do we agree on that part or someone thinks > otherwise? >
Having both makes sense to me. > The other points to bikeshed could be: > 1. The name of GUC and reloption. The two proposals at hand are > enable_parallel_dml and enable_parallel_insert. I would prefer the > second (enable_parallel_insert) because updates/deletes might not have > a similar overhead. > 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). Regards, Greg Nancarrow Fujitsu Australia
