On Mon, Jan 16, 2017 at 9:13 PM, Amit Kapila <amit.kapil...@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 WHERE a < 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers