On Fri, Nov 25, 2016 at 10:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> On Fri, Nov 25, 2016 at 3:26 AM, Andreas Seltenreich <seltenre...@gmx.de> >> wrote: >>> just caught another InitPlan below Gather with the recent patches in >>> (master as of 4cc6a3f). Recipe below. > >> I think this problem exists since commit >> 110a6dbdebebac9401b43a8fc223e6ec43cd4d10 where we have allowed >> subqueries to be pushed to parallel workers. > > The impression I got in poking at this for a few minutes, before > going off to stuff myself with turkey, was that we were allowing > a SubqueryScanPath to mark itself as parallel-safe even though the > resulting plan node would have an InitPlan attached. So my thought > about fixing it was along the lines of if-subroot-contains-initplans- > then-dont-let-SubqueryScanPath-be-parallel-safe. >
I think this will work for the reported case, see the patch attached. However, don't we need to worry about if there is a subplan (non-initplan) instead of initplan. I have tried by tweaking the above query such that it will generate a subplan and for such a case it will make SubqueryScanPath as parallel-safe. explain select 1 from public.quad_point_tbl as ref_0, lateral (select ref_0.p as c3, sample_0.d as c5 from public.nv_child_2010 as sample_0 left join public.mvtest_tvv as ref_1 on ('x' = ANY (select contype from pg_catalog.pg_constraint limit 1)) limit 82) as subq_0; > What you propose > here seems like it would shut off parallel query in more cases than > that. But I'm still full of turkey and may be missing something. > > There's another issue here, which is that the InitPlan is derived from an > outer join qual whose outer join seems to have been deleted entirely by > analyzejoins.c. Up to now it was possible to avert our eyes from the fact > that join removal is lazy about getting rid of unused InitPlans, but if > they're going to disable parallelization of the surrounding query, maybe > we need to work harder on that. > Yeah, that makes sense, but not sure whether we should try it along with this patch. > Another question worth asking is whether it was okay for the subquery to > decide to use a Gather. Are we OK with multiple Gathers per plan tree, > independently of the points above? > As of now, we don't support nested Gather case. Example: Not Okay Plan --------------------- -> Gather -> Nested Loop -> Parallel Seq Scan -> Gather -> Parallel Seq Scan Okay Plan --------------------- -> Nested Loop -> Gather -> Parallel Seq Scan -> Gather -> Parallel Seq Scan -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
allow_safe_subquery_parallel_worker_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