MIME-Version: 1.0
References: 
 <CA+TgmoYuWmN-00Ec5pY7zAcpSFQUQLbgAdVWGR9kOR-HM-fHrA@mail.gmail.com>
 <CAP53Pkzn_wZ-R-cPdD9XSQ9+myPUUsPMMqVBPNG3XWXhgfm1-Q@mail.gmail.com>
 <CA+Tgmobxbju8PrY_NULtPr7b7UShp4+Jqibm2Bou8TVS69gObQ@mail.gmail.com>
 <3683430.1775173413@sss.pgh.pa.us>
 <CA+Tgmoad!kuOMJjvYe2h6aznHFeePprGEQ8CgUpRK=47sB6DMAg@mail.gmail.com>
 <3817825.1775240432@sss.pgh.pa.us>
 <CA+TgmoY+g1u-fN=3igXG-8u0Ho3V4u-ooWXCj-FQ9DA=uGek9g@mail.gmail.com>
 <3877210.1775272486@sss.pgh.pa.us>
 <CA+TgmobOOmmXSJz3e+cjTY-bA1+W0dqVDqzxUBEvGtW62whYGg@mail.gmail.com>
 <2672940.1775599547@sss.pgh.pa.us> <adZq3Rlxq3v916aG@nathan>
 <CAAKRu_Yaarv2+SJ8qoNfMG4FCLve6KrewX_KFe1vRzk2+4d9bg@mail.gmail.com>
 <CA+TgmoaEk5nBCHCWa8epb1Fff4BwroLkdYLfqisKk49qdHGVYw@mail.gmail.com>
 <c0c63979-43c2-4424-8fe8-56949934c9d8@gmail.com>
In-Reply-To: <c0c63979-43c2-4424-8fe8-56949934c9d8@gmail.com>
From: Tender Wang <tndrwang@gmail.com>
Date: Wed, 15 Apr 2026 18:30:01 +0800
Message-ID: 
 <CAHewXNnzQJ0DofXtM3d8Ztym9ZLQ4m6MV8EezkGBG3=txS_qmw@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
 Melanie Plageman <melanieplageman@gmail.com>,
	Nathan Bossart <nathandbossart@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Lukas Fittl <lukas@fittl.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
	"heikki.linnakangas" <heikki.linnakangas@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAHewXNnzQJ0DofXtM3d8Ztym9ZLQ4m6MV8EezkGBG3%3DtxS_qmw%40mail.gmail.com>
Precedence: bulk

Alexander Lakhin <exclusion@gmail.com> =E4=BA=8E2026=E5=B9=B44=E6=9C=8815=
=E6=97=A5=E5=91=A8=E4=B8=89 02:00=E5=86=99=E9=81=93=EF=BC=9A
>
> 13.04.2026 19:01, Robert Haas wrote:
>
> Sounds like we have a consensus. I have committed the three bug-fix
> patches (unrelated to the retry-loop stuff) ...
>
>
> Thanks again for committing these fixes, Robert! With all the fixes in
> place, I and SQLsmith have reached another error:
> CREATE TABLE t1(a int);
> CREATE TABLE t2(b int);
>
> SELECT 1 FROM t1 WHERE EXISTS
>   (SELECT 1 FROM
>     (SELECT 1 FROM
>       (SELECT 1) LEFT JOIN t2 ON true),
>     t2 WHERE a =3D b);
>
> ERROR:  XX000: unique semijoin found for relids (b 3 5 7) but not observe=
d during planning
> LOCATION:  pgpa_plan_walker, pgpa_walker.c:153
>
> Could you please have a look?
>
I did some research, and  the sj_unique_rtis contains {3,5,6,7}.
You can see that 6 is in the set. How 6 is added into the uniquerel->relids=
.
After deconstruct_jointree(), the joinlist is as follow:
(gdb) call nodeToString(joinlist)
$1 =3D 0x1ef1238 "({RANGETBLREF :rtindex 1} {RANGETBLREF :rtindex 7}
{RANGETBLREF :rtindex 5} {RANGETBLREF :rtindex 3})"
You can see that no 6 in the list.
The 6 is added when processing (7, 5), in make_join_rel(), we have below lo=
gic:

   /*
    * Add outer join relid(s) to form the canonical relids.  Any added oute=
r
    * joins besides sjinfo itself are appended to pushed_down_joins.
    */
   joinrelids =3D add_outer_joins_to_relids(root, joinrelids, sjinfo,
                                 &pushed_down_joins);

In this case, 6 was added to the joinrelids.
When processing {1}, {3,5,6,7}, the {3,5,6,7} is the uniquerel, so in
the pgpa_join_path_setup(),
the {3,5,6,7} was appended to proot->sj_unique_rels.

In the plan_showdown phase, in pgpa_qf_add_plan_rtis(), we can add 7,
5, and 3 to qf->relids.
It seems difficult to add "6" to qf->relids when walking through the
plan tree.(Maybe have an easy way, I don't know too much
pg_plan_advice related code).

--=20
Thanks,
Tender Wang