Re: BUG #19653: "variable not found in subplan target list" during planning with parallel parameterized nested loop,

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Sat, Sep 5, 2026 at 8:09 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>> It seems to me the root cause is that in a partitionwise child join,
>> root->curOuterRels holds child relids, but PlaceHolderInfo.ph_eval_at
>> is always expressed in top-parent relids. So in
>> replace_nestloop_params_mutator the subset check fails for a PHV
>> evaluated at the outer child rel.

> The required-outer set passed to identify_current_nestloop_params()
> has the same problem.

Right. (For anyone following along at home, the new test case fails
with "variable not found in subplan target list" if you run it against
HEAD. You need to apply the first part of Richard's patch to get to
"failed to assign all NestLoopParams to plan nodes".)

> Attached is a patch to fix both bugs.

Hmm, I'm not enamored of just union'ing the top_parent_relids with the
regular relids. I don't see us doing that anywhere else, so it smells
like a shortcut. Shouldn't we remove the child relids while adding
the parent relids?

> (I'm surprised it has taken us so long to find these bugs. I suspect
> part of the reason is that partitionwise join is disabled by default.

Probably.

> AFAICS, enable_partitionwise_join and enable_partitionwise_aggregate
> are the only planner method GUCs that are off by default. I wonder if
> we should turn them on by default, so that bugs in these areas get
> found sooner.)

I've not paid close attention to that stuff, but I had the impression
that it is disabled-by-default because it adds materially to planning
time and we don't trust the associated cost estimates too much.
Robert might have a better-informed opinion though.

regards, tom lane