Message-ID: <f7bbf789-e8d9-4a8c-8a16-cf54088c75de@gmail.com>
Date: Mon, 6 Apr 2026 15:22:04 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pg_plan_advice
To: Robert Haas <robertmhaas@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>
References: 
 <CA+TgmoZ-Jh1T6QyWoCODMVQdhTUPYkaZjWztzP1En4=ZHoKPzw@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>
 <b579a829-987c-4a96-bbee-40b65fd18c81@gmail.com>
 <CA+TgmoZe2qEF45NL5GqxJ5OOygzd7LoVG+1iRCjUt7pXcd1aLQ@mail.gmail.com>
Content-Language: en-US
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CA+TgmoZe2qEF45NL5GqxJ5OOygzd7LoVG+1iRCjUt7pXcd1aLQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/f7bbf789-e8d9-4a8c-8a16-cf54088c75de%40gmail.com>
Precedence: bulk

On 06/04/2026 14:47, Robert Haas wrote:
> On Sun, Apr 5, 2026 at 3:57 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
>> Looking back at the pg_plan_advice development cycle, I don’t see many
>> discussions about the design. It seems unusual given how complex the
>> planner's structure is. It makes sense to follow the typical way and let
>> it serve out of the contrib for some time and see if it works well.
> But I do not apologize for the fact that pg_plan_advice tries to
> interpret plan trees -- which I personally think is one of the best
> design decisions I have ever made while hacking on PostgreSQL -- or
> that it can't interpret the variant ones that your extension produces.

I challenge solely the design of the extension, not interested in holy 
wars on the hinting approach.
Postgres modules that use hooks are second-class citizens because the 
core hooks were never designed to let an extension module be as 
effective as the core code. It's probably OK, considering safety and 
maintainability concerns.
But this extension effectively makes alternative modules third-class 
citizens (not sure such a term exists in English) - people prioritise 
contrib modules over any others. And they definitely will use this one. 
So, I envision complaints about conflicting extensions in the near 
future - think about Citus or TimescaleDB optimisations, for example.
It would be better to introduce such a code at the beginning of the 
development cycle, not right before the code freeze. At least we would 
discuss its design without rushing.

-- 
regards, Andrei Lepikhov,
pgEdge