Re: [HACKERS] parallelize queries containing subplans
От | Dilip Kumar |
---|---|
Тема | Re: [HACKERS] parallelize queries containing subplans |
Дата | |
Msg-id | CAFiTN-tq_9wsofNNa_7a9atdCgOmKs60NHazAS7Z2AzOvEiK8A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] parallelize queries containing subplans (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] parallelize queries containing subplans
Re: [HACKERS] parallelize queries containing subplans |
Список | pgsql-hackers |
On Mon, Jan 16, 2017 at 9:13 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > After commit-ab1f0c8, this patch needs a rebase. Attached find > rebased version of the patch. > > Thanks to Kuntal for informing me offlist that this patch needs rebase. In this patch, I have observed some changes while creating subplan for CTE. So I have reviewed this from that perspective and also tried to perform some test. Here is my finding/ comments. @@ -1213,6 +1216,7 @@ SS_process_ctes(PlannerInfo *root) &splan->firstColCollation); splan->useHashTable = false; splan->unknownEqFalse= false; + splan->parallel_safe = best_path->parallel_safe; I noticed that if path for CTE is parallel safe then we are marking CTE subplan as parallel safe, In particular, I don't have any problem with that, but can you add some test case which can cover this path, I mean to say where CTE subplan are pushed. ------------ I have tried to test the subplan with CTE below is my test. create table t1(a int , b varchar); create table t (n int, b varchar); Query: explain verbose select * from t where t.n not in (WITH RECURSIVE t(n) AS ( VALUES (1) UNION ALL SELECT a+1 FROM t1 WHEREa < 100 ) SELECT sum(n) FROM t); 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, (WITH RECURSIVE t(n) AS ( VALUES (1) UNION ALL SELECT a+1 FROM t1 WHERE a < 100 ) SELECT sum(n) FROM t); ---------- -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: