Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not? - Mailing list pgsql-hackers

From Andy Fan
Subject Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?
Date
Msg-id CAKU4AWr_9rq_dqa=SaRL8QaL=z4LJAuL5wqtY4U82=ts14v7dw@mail.gmail.com
Whole thread Raw
In response to Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Condition pushdown: why (=) is pushed down into join, but BETWEEN or >= is not?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Thanks for the detailed explanation. 

On Sat, Feb 19, 2022 at 2:27 AM Robert Haas <robertmhaas@gmail.com> wrote:
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, 

I didn't expect that we could commit it very soon;)   Actually my expectation
was that more people would care about the direction of this feature.  I care
about it, but that's not enough obviously.  So I summarized the direction I
want to go, and let more people see if that's right.  
  
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,

Agreed.  IMO,  the estimation error looks like a serious issue that we
all agree to find a solution.  But currently we have different ways to handle
that. I'd pretty much hope that we can have a discussion about this stuff. 

and the patches appear to be at a POC level at this point rather than 
something that's close to being ready to ship, 

This is very true since no consensus on an approach so far. PoC would
be enough for now.
 
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 truly understand this and no matter which approach I insist on, the
only reason is just because I think it is the best one IMO and not because
it comes from me or not. 
 
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.

This is the fact I think. 
 
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.
 
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.

 
New knowledge gained from  how committers think about  other's patch:) 
It is reasonable.  Committing the patch is not my only goal.  Thinking
stuff more completely is also an awesome thing to get during discussion.
Just that sometimes ignorance is frustrating (I also truly understood
that everyone's energy is limited). 

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.

+1.  Just to be more precise,  are you also confused about why this
should not be done at all.  IIUC, I get 3 reasons from Tom's reply. 
a). Planning cost. b). estimation error.  c)  extra qual execution is bad.    
 
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.

+1. 

--
Best Regards
Andy Fan

pgsql-hackers by date:

Previous
From: Michail Nikolaev
Date:
Subject: Re: Slow standby snapshot
Next
From: "kato-sho@fujitsu.com"
Date:
Subject: RE: Synchronizing slots from primary to standby