On Tue, Mar 15, 2016 at 12:21 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > On Mon, Mar 14, 2016 at 9:18 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > > > > > The failure cases fall into that category, basically wholePlanParallelSafe > > will be false, but parallelModeNeeded will be true which will enable > > parallel mode restrictions even though the plan won't contain Gather node. > > I think if we want to operate in above way for testing purpose, then we need > > to force during execution that statements for non read-only operations > > should not enter into parallel mode similar to what we are doing for > > non-zero tuple count case. Attached patch fixes the problem. > > This seems like a really ugly fix. It might be possible to come up > with a fix along these lines, but I don't have much confidence in the > specific new test you've injected into executePlan(). Broadly, any > change of this type implicitly changes the contract between > executePlan() and the planner infrastructure - the planner can now > legally generate parallel plans in some cases where that would > previously have been unacceptable. But I'm not in a hurry to rethink > where we've drawn the line there for 9.6. Let's punt this issue for > now and come back to it in a future release. >
No issues. I felt that it might be good to support parallel query via Prepare statement as there is no fundamental issue in the same, but as you say, we can do that in future release as well.