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

Thanks for the detailed explanation.

On Sat, Feb 19, 2022 at 2:27 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Fri, Feb 18, 2022 at 12:56 AM Andy Fan <zhihui(dot)fan1213(at)gmail(dot)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