Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? - Mailing list pgsql-hackers
From | Robert Haas |
---|---|
Subject | Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? |
Date | |
Msg-id | CA+TgmoZ89OpOCzXebNppQrU_wtQYimkHY3q3rWnS6ZmihA92+A@mail.gmail.com Whole thread Raw |
In response to | Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? (Andy Fan <zhihui.fan1213@gmail.com>) |
Responses |
Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
|
List | pgsql-hackers |
On Fri, Feb 18, 2022 at 12:56 AM Andy Fan <zhihui.fan1213@gmail.com> wrote: > What do you think about moving on this feature? The items known by me > are: 1). Make sure the estimation error can be fixed or discuss if my current > solution is workable. b). Just distribute some selectivity restrictinfo to > RelOptInfo. c). See how hard it is to treat the original / derived qual equally. > d). Reduce the extra planner cost at much as possible. Any other important > items I missed? I think it's not realistic to do anything here for PostgreSQL 15. Considering that it's almost the end of February and feature freeze will probably be in perhaps 5-6 weeks, in order to get something committed at this point, you would need to have (1) sufficient consensus on the design, (2) a set of reasonably complete patches implementing that design at an acceptable level of quality, and (3) a committer interested in putting in the necessary time to help you get this over the finish line. As far as I can see, you have none of those things. Tom doesn't think we need this at all, and you and I and Tomas all have somewhat different ideas on what approach we ought to be taking, and the patches appear to be at a POC level at this point rather than something that's close to being ready to ship, and no committer has expressed interest in trying to get them into this release. It seems to me that the thing to do here is see if you can build consensus on an approach. Just saying that we ought to think the patches you've already got are good enough is not going to get you anywhere. I do understand that the political element of this problem is frustrating to you, as it is to many people. But consider the alternative: suppose the way things worked around here is that any committer could commit anything they liked without needing the approval of any other committer, or even over their objections. Well, it would be chaos. People would be constantly reverting or rewriting things that other people had done, and everybody would probably be pissed off at each other all the time, and the quality would go down the tubes and nobody would use PostgreSQL any more. I'm not saying the current system is perfect, not at all. It's frustrating as all get out at times. But the reason it's frustrating is because the PostgreSQL community is a community of human beings, and there's nothing more frustrating in the world than the stuff other human beings do. However, it's equally true that we get further working together than we would individually. I think Tom is wrong about the merits of doing something in this area, but I also think he's incredibly smart and thoughtful and one of the best technologists I've ever met, and probably just one of the absolute best technologists on Planet Earth. And I also have to consider, and this is really important, the possibility that Tom is right about this issue and I am wrong. So far Tom hasn't replied to what I wrote, but I hope he does. Maybe he'll admit that I have some valid points. Maybe he'll tell me why he thinks I'm wrong. Maybe I'll learn about some problem that I haven't considered from his response, and maybe that will lead to a refinement of the idea that will make it better. I don't know, but it's certainly happened in plenty of other cases. And that's how PostgreSQL gets to be this pretty amazing database that it is. So, yeah, building consensus is frustrating and it takes a long time and sometimes it feels like other people are obstructing you needlessly and sometimes that's probably true. But there's not a realistic alternative. Nobody here is smart enough to create software that is as good as what all of us create together. -- Robert Haas EDB: http://www.enterprisedb.com
pgsql-hackers by date: