Re: [HACKERS] parallelize queries containing subplans
От | Dilip Kumar |
---|---|
Тема | Re: [HACKERS] parallelize queries containing subplans |
Дата | |
Msg-id | CAFiTN-uAb1ys1j6T7dcRGNO98kCm7OA2wVdcK+ZG3MPAaRw5Cw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] parallelize queries containing subplans (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: [HACKERS] parallelize queries containing subplans
Re: [HACKERS] parallelize queries containing subplans |
Список | pgsql-hackers |
On Thu, Jan 19, 2017 at 3:05 PM, Dilip Kumar <dilipbalaut@gmail.com> wrote: > During debugging I found that subplan created for below part of the > query is parallel_unsafe, Is it a problem or there is some explanation > of why it's not parallel_safe, Okay, so basically we don't have any mechanism to perform parallel scan on CTE. And, IMHO subplan built for CTE (using SS_process_ctes) must come along with CTE scan. So I think we can avoid setting below code because we will never be able to test its side effect, another argument can be that if we don't consider the final effect, and just see this subplan then by logic it should be marked parallel-safe or unsafe as per it's path and it will not have any side effect, as it will finally become parallel-unsafe. So it's your call to keep it either way. @@ -1213,6 +1216,7 @@ SS_process_ctes(PlannerInfo *root) &splan->firstColCollation); splan->useHashTable = false; splan->unknownEqFalse= false; + splan->parallel_safe = best_path->parallel_safe; -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: