MIME-Version: 1.0
References: 
 <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@mail.gmail.com>
 <CA+TgmoZUN8FT1Ah=m6Uis5bHa4FUa+_hMDWtcABG17toEfpiUg@mail.gmail.com>
 <CA+TgmoYh2-kM+tscOz=jVYq9Tf4SRPVqzPojs3KLZcW6E9m1BQ@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>
In-Reply-To: <2e7bdb5d-68ba-4c65-9931-a865ab6fc3d2@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Sat, 4 Apr 2026 18:52:21 -0400
Message-ID: 
 <CA+TgmoaPgXYYEivQWxyVV=eYhN+T9JAgS9Xe4m7g9wVitVPF8g@mail.gmail.com>
Subject: Re: pg_plan_advice
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alexander Lakhin <exclusion@gmail.com>,
	Lukas Fittl <lukas@fittl.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%2BTgmoaPgXYYEivQWxyVV%3DeYhN%2BT9JAgS9Xe4m7g9wVitVPF8g%40mail.gmail.com>
Precedence: bulk

On Sat, Apr 4, 2026 at 5:02=E2=80=AFPM Andrei Lepikhov <lepihov@gmail.com> =
wrote:
> That=E2=80=99s exactly what concerns me. I see it as a potential design f=
law if
> the extension has to make assumptions about possible plan configurations.
> I=E2=80=99m not sure how it works in detail, of course. However, when I d=
esigned
> Postgres replanning in the past, and made similar core changes to what
> you=E2=80=99ve done for pg_plan_advice, this kind of problem couldn=E2=80=
=99t have
> happened. So, I think it=E2=80=99s worth questioning the current approach=
 and
> looking for other options.

I mean, any plan stability feature is intrinsically tied to a
particular planner. Nobody thinks you can use Aurora Postgres's Query
Plan Management feature with MySQL or DB2 or Oracle. Those products
obviously have to have their own features for plan stability. The same
is true here. There's more overlap because you're creating the plan
out of the same basic building blocks rather than an entirely
different set of things, but if you assemble them in a way that
PostgreSQL doesn't, then some things may not work. pg_plan_advice is
one of those things; the executor is another. Of course, I don't think
anybody here is keen to break stuff for no good reason, which is why I
will take a look at the report you posted. But fundamentally, it's the
same issue. If somebody uses a plugin that replaces large parts of the
plan with a CustomScan, pg_plan_advice isn't going to work with that,
either: how could it possibly? Maybe there could be some way to make
pg_plan_advice pluggable so that if extensions fiddle with the planner
they can also do matching fiddling with pg_plan_advice if they're so
inclined, but having it "just work" would require magic.

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