Feedback-ID: id4a34324:Fastmail
Date: Mon, 6 Apr 2026 09:56:23 -0400
From: Andres Freund <andres@anarazel.de>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Alexander Lakhin <exclusion@gmail.com>, Lukas Fittl <lukas@fittl.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_plan_advice
Message-ID: <t27zi5nzsazkxlhvrrbbaaeqso7huqmtuoxtyk6vpdvl4xlx5c@eahhvqesniqn>
References: 
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2e7bdb5d-68ba-4c65-9931-a865ab6fc3d2@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/t27zi5nzsazkxlhvrrbbaaeqso7huqmtuoxtyk6vpdvl4xlx5c%40eahhvqesniqn>
Precedence: bulk

Hi,

On 2026-04-04 23:02:37 +0200, Andrei Lepikhov wrote:
> On 4/4/26 20:42, Robert Haas wrote:
> > On Sat, Apr 4, 2026 at 5:34 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
> > By the way, I'm really glad you hit that error. That particular error
> > check is there precisely to find plans that pg_plan_advice isn't able
> > to understand, and it sounds like it is doing its job as intended.
> > Having problems isn't great, but knowing that you have problems is a
> > lot better than still having them but not knowing about it.
> That’s exactly what concerns me. I see it as a potential design flaw if the
> extension has to make assumptions about possible plan configurations.
> I’m not sure how it works in detail, of course. However, when I designed
> Postgres replanning in the past, and made similar core changes to what
> you’ve done for pg_plan_advice, this kind of problem couldn’t have happened.
> So, I think it’s worth questioning the current approach and looking for
> other options.

You're making sweeping high-level demands, implying they're easy ("when I
designed ... this kind of problem couldn’t have happened"), without any
concrete technical suggestions for how to actually achieve that.  In very
strong language.  Your high level demand, that somehow plan shape influencing
code should just work regardless of what crazy thing extensions have done
seems ... not entirely realistic, to put it very kindly.

I suggest you rethink your approach of engaging with others.

Greetings,

Andres Freund