MIME-Version: 1.0
References: 
 <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CA+TgmoaK=4w7-qknUo3QhUJ53pXZq=c=KgZmRyD+k7ytqfmgSg@mail.gmail.com>
 <CAP53Pkz3DSFaaowYvbO5LULf3NhydD_UhHkighfWf6_pwxiqUw@mail.gmail.com>
 <CA+TgmoZ45n5jaNKKgbbj4-kYV8WsPvUn=Z8HnoZ7tUb_p9WKXg@mail.gmail.com>
 <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+TgmoadkuOMJjvYe2h6aznHFeePprGEQ8CgUpRK=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>
 <386d8c06-0f96-40bb-b1b1-107db209c676@gmail.com>
 <CA+Tgmoben3_8rZbQ2X2+gOBOFpOgkc9hx3-z9e_Q_kHCfuW25g@mail.gmail.com>
 <2e7bdb5d-68ba-4c65-9931-a865ab6fc3d2@gmail.com>
 <CA+TgmoaPgXYYEivQWxyVV=eYhN+T9JAgS9Xe4m7g9wVitVPF8g@mail.gmail.com>
 <ffb3efc9-d709-46ef-b180-e8f0c068ba51@gmail.com>
In-Reply-To: <ffb3efc9-d709-46ef-b180-e8f0c068ba51@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Mon, 6 Apr 2026 15:52:51 -0400
Message-ID: 
 <CA+TgmoaS3fWeyyfKtX93NhmAh=bd0auqW_+XgcTJ5rrMr4qo9w@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Lukas Fittl <lukas@fittl.com>,
	Andrei Lepikhov <lepihov@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoaS3fWeyyfKtX93NhmAh%3Dbd0auqW_%2BXgcTJ5rrMr4qo9w%40mail.gmail.com>
Precedence: bulk

On Sun, Apr 5, 2026 at 4:00=E2=80=AFAM Alexander Lakhin <exclusion@gmail.co=
m> wrote:
> I and SQLsmith have discovered one more anomaly (reproduced starting from
> e0e4c132e):
> load 'test_plan_advice';
> select object_type from
>   (select object_type from information_schema.element_types limit 1),
>   lateral
>   (select sum(1) over (partition by a) from generate_series(1, 2) g(a) wh=
ere false);
>
> triggers an internal error:
> ERROR:  XX000: no rtoffset for plan unnamed_subquery
> LOCATION:  pgpa_plan_walker, pgpa_walker.c:110
>
> Could you please have a look?

Thanks for the report. What seems to be happening here is that the
whole query is replaced by a single Result node, since the join must
be empty. But that means that unnamed_subquery doesn't make it into
the final plan tree, and then pgpa_plan_walker() is sad about not
finding it. Normally it wouldn't care, but apparently this query
involves at least one semijoin someplace that the planner considered
converting into a regular join with one side made unique, so
pgpa_plan_walker() has an entry in sj_unique_rels and then wants to
adjust that entry for the final, flattened range table, and it can't.
I'm inclined to think that the fix is just:

-            elog(ERROR, "no rtoffset for plan %s", proot->plan_name);
+            continue;

...plus a comment update, but I want to spend some time mulling over
whether that might break anything else before I go do it.

--=20
Robert Haas
EDB: http://www.enterprisedb.com