Yep. In select … from a join b join c join d
join is a left-associative binary operator. The effect is as if you wrote select … from ((a join b) join c) join d And it doesn’t matter whether a, b, c and d are tables or sub-queries. Julian > On May 31, 2017, at 8:19 AM, Muhammad Gelbana <[email protected]> wrote: > > So If I have a JdbcJoin node with the inputs (*JdbcTableScan* & > *JdbcJoin *(With > 2 *JdbcTableScan*s as input)), the whole join composed of the 3 tables is > implemented in a single SQL statement. > > I thought a *JdbcJoin* node can be composed of only *JdbcTableScan* nodes > but after I tried what you said, it's working as I want it to now. > > *---------------------* > *Muhammad Gelbana* > http://www.linkedin.com/in/mgelbana > > On Tue, May 30, 2017 at 10:36 PM, Julian Hyde <[email protected]> wrote: > >> What do you mean by “multi join”? Join is a binary operation. You can >> group more than one join together (e.g. a join b join c all on the same >> join key) but it’s just an optimization; it does the same as pair-wise >> joins. >> >> We have multi-join internally — it allows us to determine join order for a >> large number of joins with reasonable efficiency — but the multi-join is >> expanded to pair-wise joins for later phases in the planing process. >> MultiJoin has complex semantics so it is difficult to make it interact with >> other relational operators. >> >> Julian >> >> >>> On May 28, 2017, at 5:16 AM, Muhammad Gelbana <[email protected]> >> wrote: >>> >>> My ultimate goal is to pushdown joins from Drill to a JDBC datasource. >>> >>> To do that, I wrote a converter rule to convert LogicalJoins >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> rel/logical/LogicalJoin.html> >>> to >>> a custom descendant of the JdbcJoin >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> adapter/jdbc/JdbcRules.JdbcJoin.html> >>> class >>> which worked fine so far. >>> >>> Now I need to do the same for multi joins too but I believe 3 classes are >>> missing. >>> >>> 1. A JdbcRel >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> adapter/jdbc/JdbcRel.html> >>> descendant >>> (Not JdbcJoin >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> adapter/jdbc/JdbcRules.JdbcJoin.html>, >>> because it extends BiRel >>> <https://calcite.apache.org/apidocs/org/apache/calcite/rel/BiRel.html> >> which >>> wouldn't be valid because we are considering a node with more than two >>> operands) for multijoins (Example: *JdbcMultiJoin*) >>> 2. A SqlCall >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> sql/SqlCall.html>\ >>> SqlJoin >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> sql/SqlJoin.html> >>> descendant >>> for multijoins (Example: *SqlMultiJoin*) to be created while >> implementing >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> adapter/jdbc/JdbcRel.html#implement-org.apache.calcite. >> adapter.jdbc.JdbcImplementor-> >>> the *JdbcMultiJoin* class. >>> 3. A JDBC rule for converting MultiJoins >>> <https://calcite.apache.org/apidocs/org/apache/calcite/ >> rel/rules/MultiJoin.html> >>> to >>> the newly created *JdbcMultiJoin* >>> >>> Am I correct or is this already implemented somewhere ? >>> >>> *---------------------* >>> *Muhammad Gelbana* >>> http://www.linkedin.com/in/mgelbana >> >>
