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
