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 23:30:33 -0400
Message-ID: <157316.1788751833@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMbWs49tzZzriJGqZ+1y7njh0=4sMGm3vOvAUmBo8r_Yqp=1SQ@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>
<116500.1788717110@sss.pgh.pa.us>
<CAMbWs49tzZzriJGqZ+1y7njh0=4sMGm3vOvAUmBo8r_Yqp=1SQ@mail.gmail.com>
Richard Guo <guofenglinux@gmail.com> writes:
> On Mon, Sep 7, 2026 at 2:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?
> Yeah, we don't union child relids and parent relids anywhere else, and
> I'm not entirely happy with it either. But I'm not sure we can simply
> remove the child relids here, because the same set is used for two
> different membership tests. For Vars, we check whether var->varno is
> a member of the set, and within a child join the Vars carry child
> relids. For PlaceHolderVars, we check whether ph_eval_at is a subset
> of the set, and ph_eval_at always carries parent relids. So, AFAICS,
> the set needs the child relids for the Var test and the parent relids
> for the PHV test, and dropping the child relids would break the Var
> test.
Yeah, I tried adjusting things like that and the regression tests
immediately crashed. So now I think we have to do it as you have it;
but maybe the comment could be improved to explain that we need to
match both Vars having the child relid and PHVs having top-parent
relids. (Could there be Vars having the parent relid? Not sure,
but if there are, I suppose we'd need to match them too.)
> Maybe an alternative is to keep the set in top-parent terms and
> translate each Var's varno to its top parent before the membership
> test, or to leave the set alone and instead translate ph_eval_at into
> child relids before the subset test. But AFAICS we need to update
> quite a few places to make either way work, such as
> replace_nestloop_params_mutator(), identify_current_nestloop_params(),
> process_subquery_nestloop_params(), and maybe more. Not sure if this
> is a better option.
Agreed. Quite aside from the number of places that'd have to be
touched, I'm not too comfortable with rethinking those design
decisions in a hasty back-patch. It seems not unlikely that
extensions contain code that expects the current data structure
definitions.
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: <157316.1788751833@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