Re: pg_plan_advice

Alexander Lakhin <exclusion(at)gmail(dot)com> 于2026年4月15日周三 02:00写道：
>
> 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 = b);
>
> ERROR: XX000: unique semijoin found for relids (b 3 5 7) but not observed 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 = 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 logic:

/*
* Add outer join relid(s) to form the canonical relids. Any added outer
* joins besides sjinfo itself are appended to pushed_down_joins.
*/
joinrelids = 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).

--
Thanks,
Tender Wang