On 3/9/2025 11:12, Richard Guo wrote:
On Tue, Sep 2, 2025 at 7:56 PM Andrei Lepikhov <[email protected]> wrote:
No questions, it is good enough optimisation. I'm worried only about
implementation: It creates one more RelOptInfo that may look like a
baserel, but we can't find it by find_base_rel or even find_join_rel. It
seems a little inconsistent to me.
Don't think it is critical - just complicates life for extension
developers in some cases.
The RelOptInfo representing the unique-ified rel is intended to be
used only internally during path generation for semi-joins, and should
be opaque outside of that. I don't think extensions should know about
it.
I just stated the fact - it is not for debate ;).
To understand how deeply developers utilise the core, take a look at the
pg_hint_plan. The extensibility of the Postgres planner isn't flexible
enough (and will never be) for the developers' purposes. So, they
exploit every exported function, variable and type.
Every feature intended to be hidden from extensions should be wrapped
into an internal type, not exposed in .h files.
It leads us to a discussion about the voice of extension developers in
the core decisions. I think it is worth debating at one of the
conferences in the near future.
--
regards, Andrei Lepikhov
