From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: 10215501441@stu.ecnu.edu.cn, Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19653: "variable not found in subplan target list" during planning with parallel parameterized nested loop,
Date: Sun, 06 Sep 2026 13:51:50 -0400
Message-ID: <116500.1788717110@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMbWs48OyF+JAiP-c3YxswVTK1mbjO-RNWFB0JXV7xdaC6HmPg@mail.gmail.com>
References: <19653-9352cc6ba17b662f@postgresql.org>
<1564958.1788530496@sss.pgh.pa.us>
<1570204.1788535631@sss.pgh.pa.us>
<CAMbWs4_aJo_wEQCzT=mLBSQEdKt-J0OM5weZtt-szZSKvnPusw@mail.gmail.com>
<CAMbWs48OyF+JAiP-c3YxswVTK1mbjO-RNWFB0JXV7xdaC6HmPg@mail.gmail.com>
Richard Guo <guofenglinux@gmail.com> writes:
> On Sat, Sep 5, 2026 at 8:09 AM Richard Guo <guofenglinux@gmail.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, guofenglinux@gmail.com, robertmhaas@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19653: "variable not found in subplan target list" during planning with parallel parameterized nested loop,
In-Reply-To: <116500.1788717110@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox