On Mon, May 6, 2024 at 12:01 PM Andrei Lepikhov <a.lepik...@postgrespro.ru> wrote: > 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.
Well, as I said before, I think self-join elimination is a good feature, and I believe that it belongs in PostgreSQL. However, I don't believe that this implementation was done as well as it needed to be done. A great deal of the work involved in a feature like this lies in figuring out at what stage of processing certain kinds of transformations ought to be done, and what cleanup is needed afterward. It is difficult for anyone to get that completely right the first time around; left join elimination also provoked a series of after-the-fact bug fixes. However, I think those were fewer in number and spread over a longer period of time. Now that being said, I do also agree that the planner code is quite hard to understand, for various reasons. I don't think the structure of that code and the assumptions underlying it are as well-documented as they could be, and neither do I think that all of them are optimal. It has taken me a long time to learn as much as I know, and there is still quite a lot that I don't know. And I also agree that the planner does an unfortunate amount of in-place modification of existing structures without a lot of clarity about how it all works, and an unfortunate amount of data copying in some places, and even that the partition-wise join code isn't all that it could be. But I do not think that adds up to a conclusion that we should just be less ambitious with planner changes. Indeed, I would like to see us do more. There is certainly a lot of useful work that could be done. The trick is figuring out how to do it without breaking too many things, and that is not easy. -- Robert Haas EDB: http://www.enterprisedb.com
