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. 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.
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?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
