Re: [PATCH] Allow parallelism for plpgsql return expression after commit 556f7b7

On Fri, Jul 4, 2025 at 9:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Dilip Kumar <dilipbalaut@gmail.com> writes:
> > On Fri, Jul 4, 2025 at 1:22 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> There's no initplan in the given test case, so I don't see how
> >> that idea is going to fix it.  Also, allowing initplans to begin
> >> parallelism when the outer query isn't using parallelism seems
> >> like it'd be fraught with problems.  It certainly couldn't be
> >> something we'd back-patch.
>
> > If you see the original problematic case[1] shown by dipesh, where the
> > parallel plan is selected for the initPlan1 but it could not launch
> > the worker because of the below check[2] in ExecutePlan.  So here my
> > concern was that the number of "max tuple" was passed for the top
> > level plan, however the parallelism is restricted for the InitPlan as
> > well.
>
> Oh, looking back, I see that indeed the original example happened to
> produce a plan that involves an initplan.  But there are plenty of
> variants that won't, such as the arguably-more-idiomatic
>
>         return count(*) from test_tab where a between 5.0 and 999999.0;
>
> So I think your emphasis on improving that case is misplaced to start
> with.
>
> > If I understand the code comments correctly, they state that "Parallel
> > mode only supports complete execution of a plan." Given that
> > "InitPlan1" does run to completion, it seems the issue here is that
> > when the top-level plan isn't fully executed, it restricts parallelism
> > for its sub-plans or init-plans, even if those sub-plans are running
> > to completion.
>
> I repeat that I don't think "allow an initplan to run in parallel even
> if the outer query can't" is a particularly sane way to tackle this
> problem.  For starters, ExecutorRun calls EnterParallelMode() and
> ExitParallelMode() globally for the entire query.  We'd have to
> rethink how that works and when it would be safe to call those.
> Using the query-global estate->es_use_parallel_mode flag wouldn't work
> either.  Thought would also be needed about which can't-do-parallelism
> restrictions would be safe to override.  I agree that an outer
> numberTuples restriction needn't be considered, but I'm not sure that
> any others could be ignored.
>
> So on the whole it seems like a research project requiring nontrivial
> effort and probably yielding only marginal gains.  It's certainly not
> going to yield a back-patchable fix for this performance regression.

Yeah that's correct.

--
Regards,
Dilip Kumar
Google