On Mon, Mar 8, 2021 at 7:19 PM Amit Langote <amitlangot...@gmail.com> wrote: > > Hi Amit > > On Mon, Mar 8, 2021 at 10:18 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Mar 8, 2021 at 3:54 PM Greg Nancarrow <gregn4...@gmail.com> wrote: > > > I've attached an updated set of patches with the suggested locking > > > changes. > > (Thanks Greg.) > > > Amit L, others, do let me know if you have still more comments on > > 0001* patch or if you want to review it further? > > I just read through v25 and didn't find anything to complain about. >
Thanks a lot, pushed now! Amit L., your inputs are valuable for this work. 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? 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. 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. Thoughts? -- With Regards, Amit Kapila.
