On Fri, Feb 26, 2016 at 4:37 PM, Robert Haas <robertmh...@gmail.com> wrote: > > > And, I'm going to revert this part. If you'd run the regression tests > under force_parallel_mode=regress, max_parallel_degree>0, you would > have noticed that this part breaks it, because of CREATE TABLE ... AS > EXECUTE. >
I have looked into this issue and found that the reason for the failure is
that in force_parallel_mode=regress, we enable parallel mode restrictions
even if the parallel plan is not choosen as part of below code in
standard_planner()
if (force_parallel_mode == FORCE_PARALLEL_OFF || !glob->parallelModeOK)
{
glob->parallelModeNeeded = false;
glob->wholePlanParallelSafe = false; /* either false or don't care */
}
else
{
glob->parallelModeNeeded = true;
glob->wholePlanParallelSafe =
!has_parallel_hazard((Node *) parse, false);
}
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.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
prepared_stmt_parallel_query_v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
