fix: skip EliminateCrossJoin rule if inner join with filter is found

[epsio-banay]

Which issue does this PR close?

Closes #7530

Rationale for this change

Explained in issue

What changes are included in this PR?

EliminateCrossJoin optimization rule should be skipped for InnerJoin with filter, this PR fixes a bug were nested InnerJoins with filter do not cause the rule to be skipped.

Are these changes tested?

yes see eliminate_cross_not_possible_nested_inner_join_with_filter

Are there any user-facing changes?

There are no API changes but query results might differ.

[alamb]

Thank you for the contribution @epsio-banay -- @jackwener or @liukun4515 would you have time to review this PR?

[jackwener]

Thanks @epsio-banay , good catch!

LGTM.

BTW, I'm thinking about this whole method. I think we don't need differentiate between handling equal conditions and non-equal conditions, because multi join is a Query Graph and both equal conditions and non-equal conditions are edges in Graph. But I also think this is a longer-term problem. I prepare to do this job in 1-2 weeks.

[alamb]

because multi join is a Query Graph and both equal conditions and non-equal conditions are edges in Graph. But I also think this is a longer-term problem. I prepare to do this job in 1-2 weeks.

Representing the joins in a query as a JoinGraph would be very interesting. I wonder if you have an idea of where would it be done?

It could be as a pass prior to the LogicalPlan:

sql text --> Sql AST --> JoinGraph --> LogicalPlan

or you could do it as part of an optimization pass, like this:

sql text --> Sql AST  --> LogicalPlan --(optimize with JoinGraph) --> LogicalPlan

Or something else I haven't thought of :)

[alamb]

Thanks @epsio-banay and @jackwener

[jackwener]

#7549 to trace it

[jackwener]

Representing the joins in a query as a JoinGraph would be very interesting. I wonder if you have an idea of where would it be done?

Because we just want to rearrange Inner/Outer join, Use MultiJoin is enough.

          MultiJoin
       /    |    |    \
child   child   child   child .....

Collect All Inner/Cross Join into a multijoin, and then split it to become multiple join

---

If you are interested in JoinGraph, there is a good example in MySQL-8.0. It use JoinGraph to present Join Tree, and use it to finish JoinReorder with a pretty good algorithm DPHyp.

https://github.com/mysql/mysql-server/blob/trunk/sql/join_optimizer/hypergraph.h

its process is

SQL --> LogicalPlan --(optimize with JoinGraph) --> LogicalPlan

[alamb]

🤔 would a multi-join work for a query like

SELECT ..
  FROM A JOIN B ON (a.x=b.x)
     JOIN C ON (a.y = c.y AND b.z = c.z)

A join graph might look like this

(A) -- y -- (B)
   \       /
    x     z
     \   /
      (C)

Would a multi-join look like

JOIN (a.x=b.x, a.y=c.y, b.z=c.z)
  (A, B, C)

I guess then any reordering could happen as a translation from Multi-join to binary join 🤔