On Wed, Dec 9, 2020 at 10:11 AM Greg Nancarrow <gregn4...@gmail.com> wrote: > > On Wed, Dec 9, 2020 at 1:35 AM vignesh C <vignes...@gmail.com> wrote: > > > > Most of the code present in > > v9-0001-Enable-parallel-SELECT-for-INSERT-INTO-.-SELECT.patch is > > applicable for parallel copy patch also. The patch in this thread > > handles the check for PROPARALLEL_UNSAFE, we could slightly make it > > generic by handling like the comments below, that way this parallel > > safety checks can be used based on the value set in > > max_parallel_hazard_context. There is nothing wrong with the changes, > > I'm providing these comments so that this patch can be generalized for > > parallel checks and the same can also be used by parallel copy. > > Hi Vignesh, > > You are absolutely right in pointing that out, the code was taking > short-cuts knowing that for Parallel Insert, > "max_parallel_hazard_context.max_interesting" had been set to > PROPARALLEL_UNSAFE, which doesn't allow that code to be generically > re-used by other callers. > > I've attached a new set of patches that includes your suggested improvements.
I was going through v10-0001 patch where we are parallelizing only the select part. + /* + * UPDATE is not currently supported in parallel-mode, so prohibit + * INSERT...ON CONFLICT...DO UPDATE... + */ + if (parse->onConflict != NULL && parse->onConflict->action == ONCONFLICT_UPDATE) + return PROPARALLEL_UNSAFE; I understand that we can now allow updates from the worker, but what is the problem if we allow the parallel select even if there is an update in the leader? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
