On 6/5/2024 21:44, Robert Haas wrote:
> On Sat, May 4, 2024 at 10:46 PM Andrei Lepikhov
> <a.lepikhov@postgrespro.ru> wrote:
>> Having no objective negative feedback, we have no reason to change
>> anything in the design or any part of the code. It looks regrettable and
>> unusual.
>
> To me, this sounds like you think it's someone else's job to tell you
> what is wrong with the patch, or how to fix it, and if they don't,
> then you should get to have the patch as part of PostgreSQL. But that
> is not how we do things, nor should we. I agree that it sucks when you
> need feedback and don't get it, and I've written about that elsewhere
> and recently. But if you don't get feedback and as a result you can't
> get the patch to an acceptable level,
I'm really sorry that the level of my language caused a misunderstanding.
The main purpose of this work is to form a more or less certain view of
the direction of the planner's development.
Right now, it evolves extensively - new structures, variables,
alternative copies of the same node trees with slightly changed
properties ... This way allows us to quickly introduce some planning
features (a lot of changes in planner logic since PG16 is evidence of
that) and with still growing computing resources it allows postgres to
fit RAM and proper planning time. But maybe we want to be more modest?
The Ashutosh's work he has been doing this year shows how sometimes
expensive the planner is. Perhaps we want machinery that will check the
integrity of planning data except the setrefs, which fail to detect that
occasionally?
If an extensive approach is the only viable option, then it's clear that
this and many other features are simply not suitable for Postgres
Planner. It's disheartening that this patch didn't elicit such
high-level feedback.
--
regards,
Andrei Lepikhov