Re: Prepared Statement support for Parallel query
От | Amit Kapila |
---|---|
Тема | Re: Prepared Statement support for Parallel query |
Дата | |
Msg-id | CAA4eK1KxiYm8F9Pe9xvqzoZocK43w=TRPUNHZpe_iOjF=r+_Vw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Prepared Statement support for Parallel query (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Prepared Statement support for Parallel query
|
Список | pgsql-hackers |
>
>
> 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.
>
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.
Вложения
В списке pgsql-hackers по дате отправления: