Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.0-incubating
    • Component/s: None
    • Labels:
      None

      Description

      Currently, the JdbcJoin only support EquiJoin. ie select * from tab1 inner join tab2 on tab1.col1=tab2.col2

      NonEqui join are not supported in JdbcJoin, thus resulting execution plan which uses EnumerationJoin and EnumerableCalc for joining and not pushing the join down to remote database.

        Activity

        Hide
        julianhyde Julian Hyde added a comment -

        Agree, this would be useful. We might find that some databases can't support all kinds of join (e.g. some do not support FULL join) but we could cross that bridge when we come to it.

        Show
        julianhyde Julian Hyde added a comment - Agree, this would be useful. We might find that some databases can't support all kinds of join (e.g. some do not support FULL join) but we could cross that bridge when we come to it.
        Hide
        jiunnjye Ng Jiunn Jye added a comment -

        Fix in attached patch.

        With this fix, the JdbcJoin will be able to support following join
        EquiJoin => select * from tabA inner join tabB on tabA.col1 = tabA.col1
        NonEquiJoin => select * from tabA inner join tabB on tabA.col1 > tabA.col1 (and other operator)
        MixedJoin => select * from tabA inner join tabB on tabA.col1 = tabA.col1 and tabA.col2 > tabA.col2

        combination of conditions using OR is not supported.

        This fix also resolved CALCITE-597 issue.
        The JdbcJoin.getRows method is updated to return max of leftRowCount, rightRowCount. This may not be the final solution but this is required to be able to beat EnumerableJoin's cost.

        Show
        jiunnjye Ng Jiunn Jye added a comment - Fix in attached patch. With this fix, the JdbcJoin will be able to support following join EquiJoin => select * from tabA inner join tabB on tabA.col1 = tabA.col1 NonEquiJoin => select * from tabA inner join tabB on tabA.col1 > tabA.col1 (and other operator) MixedJoin => select * from tabA inner join tabB on tabA.col1 = tabA.col1 and tabA.col2 > tabA.col2 combination of conditions using OR is not supported. This fix also resolved CALCITE-597 issue. The JdbcJoin.getRows method is updated to return max of leftRowCount, rightRowCount. This may not be the final solution but this is required to be able to beat EnumerableJoin's cost.
        Hide
        julianhyde Julian Hyde added a comment -

        Some review comments.

        Patch doesn't pass check-style – needed a newline.

        There is a bug if the query is written with left and right reversed, e.g. "ON tabB.col1 < tabA.col1". You swap the args but you do not switch < to >.

        I am uncomfortable with the the idea that arguments to non-equi conditions are regarded as "keys". It is too easy to accidentally treat theta joins (e.g. x.a = y.b and x.c < y.d) as equi joins. And indeed your code makes that mistake.

        And it doesn't seem right that the overwhelmingly common cases – 90% are equi joins on 1 column, 9% equi joins on 2 or more columns – should create a list of operators.

        Please mark the old splitJoinCondition deprecated to be removed before 2.0.

        Show
        julianhyde Julian Hyde added a comment - Some review comments. Patch doesn't pass check-style – needed a newline. There is a bug if the query is written with left and right reversed, e.g. "ON tabB.col1 < tabA.col1". You swap the args but you do not switch < to >. I am uncomfortable with the the idea that arguments to non-equi conditions are regarded as "keys". It is too easy to accidentally treat theta joins (e.g. x.a = y.b and x.c < y.d) as equi joins. And indeed your code makes that mistake. And it doesn't seem right that the overwhelmingly common cases – 90% are equi joins on 1 column, 9% equi joins on 2 or more columns – should create a list of operators. Please mark the old splitJoinCondition deprecated to be removed before 2.0.
        Hide
        julianhyde Julian Hyde added a comment -

        I've been thinking further about this. Why do you need the operators list? Why can't you leave the "non-equi" parts in JdbcJoin.condition until JdbcJoin.implement is called, and then just transcribe the RexNode tree into a SqlNode tree.

        I don't see any advantage of breaking out theta operators such as < into a list, versus just leaving it all in a RexNode blob.

        Common theta cases such as "(x, y) < (x1, y1)", which becomes "x < x1 or (x = x1 and y < y1)", can't be converted into ANDs anyway.

        Show
        julianhyde Julian Hyde added a comment - I've been thinking further about this. Why do you need the operators list? Why can't you leave the "non-equi" parts in JdbcJoin.condition until JdbcJoin.implement is called, and then just transcribe the RexNode tree into a SqlNode tree. I don't see any advantage of breaking out theta operators such as < into a list, versus just leaving it all in a RexNode blob. Common theta cases such as "(x, y) < (x1, y1)", which becomes "x < x1 or (x = x1 and y < y1)", can't be converted into ANDs anyway.
        Hide
        jiunnjye Ng Jiunn Jye added a comment -

        I agree with you on processing based on JdbcJoin.condition. And I totally missed out the reverse left right in my previous patch. Thanks for pointing them out.

        CALCITE-631JdbcJoinToSupportNonEquiJoin.2.patch is new patch which converting condition RexCall into SqlJoin. The previous patch is no longer relevant.
        As the condition has all the information, the new patch is able to work on combination joins using of AND and OR. I have added test case in JdbcAdapterTest to test this as well.

        I am a bit confused with your explanation on Common theta cases. Can you provide some reference link ?

        Thank you.

        Show
        jiunnjye Ng Jiunn Jye added a comment - I agree with you on processing based on JdbcJoin.condition. And I totally missed out the reverse left right in my previous patch. Thanks for pointing them out. CALCITE-631 JdbcJoinToSupportNonEquiJoin.2.patch is new patch which converting condition RexCall into SqlJoin. The previous patch is no longer relevant. As the condition has all the information, the new patch is able to work on combination joins using of AND and OR. I have added test case in JdbcAdapterTest to test this as well. I am a bit confused with your explanation on Common theta cases. Can you provide some reference link ? Thank you.
        Hide
        julianhyde Julian Hyde added a comment -

        My point about "common theta cases" is that thetas are already an edge case – the vast majority of joins are equi joins on one or two keys – and so there is little point spending effort on thetas that are decomposable to ANDs. You need to be able to handle all thetas. I gave an example that was common among theta queries and naturally decomposes to an OR.

        Show
        julianhyde Julian Hyde added a comment - My point about "common theta cases" is that thetas are already an edge case – the vast majority of joins are equi joins on one or two keys – and so there is little point spending effort on thetas that are decomposable to ANDs. You need to be able to handle all thetas. I gave an example that was common among theta queries and naturally decomposes to an OR.
        Hide
        jiunnjye Ng Jiunn Jye added a comment - - edited

        Ok. The new patch should be able to handle those.
        I have added a test case for combination of AND OR scenario

        select e.empno, e.ename, e.empno, e.ename
        from scott.emp e inner join scott.emp m
        on e.mgr = m.empno and (e.sal > m.sal or m.hiredate > e.hiredate)

        Do you have any comment on the new patch ?

        Show
        jiunnjye Ng Jiunn Jye added a comment - - edited Ok. The new patch should be able to handle those. I have added a test case for combination of AND OR scenario select e.empno, e.ename, e.empno, e.ename from scott.emp e inner join scott.emp m on e.mgr = m.empno and (e.sal > m.sal or m.hiredate > e.hiredate) Do you have any comment on the new patch ?
        Hide
        julianhyde Julian Hyde added a comment -

        I'm trying out the new patch. The costing changes you have made to JdbcJoin cause the test suite to take about 10x longer to run, swamp all cores with garbage collection activity, and in some cases it even crash the JVM. Did you see the same when you ran the test?

        I can't accept the patch as it stands.

        I presume that the costing changes cause Jdbc plans to be used rather than Enumerable. If I disable the cost changes, JdbcAdapterTest gives different results than expected. Could you maybe run JdbcAdapterTest with EnumerableJoinRule disabled, so it would choose JdbcJoin even if it has the current cost model?

        Show
        julianhyde Julian Hyde added a comment - I'm trying out the new patch. The costing changes you have made to JdbcJoin cause the test suite to take about 10x longer to run, swamp all cores with garbage collection activity, and in some cases it even crash the JVM. Did you see the same when you ran the test? I can't accept the patch as it stands. I presume that the costing changes cause Jdbc plans to be used rather than Enumerable. If I disable the cost changes, JdbcAdapterTest gives different results than expected. Could you maybe run JdbcAdapterTest with EnumerableJoinRule disabled, so it would choose JdbcJoin even if it has the current cost model?
        Hide
        jiunnjye Ng Jiunn Jye added a comment - - edited

        The Costing changes were deliberately done to have Calcite use JdbcJoin instead of EnumerableJoin. I notice the use of JdbcConvention.COST_MULTIPLIER in some rules but JdbcJoin does not use the same calculation. In fact, it is using a totally different calculation method which in most of my test cases fail to get chosen by calcite (as you had observed when reversing the cost calculation).

        In my opinion, the number of row return from JdbcJoin should be the max of leftRowCount and rightRowCount.

        As for the test execution OutOfMemory issue. I am experiencing the same issue. I run the HeapAnalyzer on the phd file. The leak suspect shows
        315,834,864 bytes (64.23 %) of Java heap is used by 40 instances of
        org/hsqldb/persist/RowStoreAVLMemory

        I wonder if this is caused by the push down of Join stressing up on hsqldb.

        As for your suggestion to rerun JdbcAdapterTest by disabling EnumerableJoinRule. Do you have any hint/sample on how to disable EnumerableJoinRule from running a test ?

        Show
        jiunnjye Ng Jiunn Jye added a comment - - edited The Costing changes were deliberately done to have Calcite use JdbcJoin instead of EnumerableJoin. I notice the use of JdbcConvention.COST_MULTIPLIER in some rules but JdbcJoin does not use the same calculation. In fact, it is using a totally different calculation method which in most of my test cases fail to get chosen by calcite (as you had observed when reversing the cost calculation). In my opinion, the number of row return from JdbcJoin should be the max of leftRowCount and rightRowCount. As for the test execution OutOfMemory issue. I am experiencing the same issue. I run the HeapAnalyzer on the phd file. The leak suspect shows 315,834,864 bytes (64.23 %) of Java heap is used by 40 instances of org/hsqldb/persist/RowStoreAVLMemory I wonder if this is caused by the push down of Join stressing up on hsqldb. As for your suggestion to rerun JdbcAdapterTest by disabling EnumerableJoinRule. Do you have any hint/sample on how to disable EnumerableJoinRule from running a test ?
        Hide
        jiunnjye Ng Jiunn Jye added a comment -

        Found the problem.

        For your information. I have rerun with EnumerableJoinRule disabled (removing from CalcitePrepareImpl). The JVM still crash with OOM error.

        After breaking down the test suite and run them one by one, managed to identify the failure at JdbcTest.testSelfJoinCount introduced by CALCITE-70. The JdbcJoin has pushed the join operation to HSQL and the query blew up HSQL. This can be simulated by executing query on HSQL thus showing it is a HSQL issues.

        I will modify the test to run against a smaller table.

        Test Query :
        select count as c
        from "foodmart"."sales_fact_1997" as p1
        join "foodmart"."sales_fact_1997" as p2 using ("store_id")

        Generated Query after JdbcJoin:
        SELECT COUNT AS "C"
        FROM (SELECT 0 AS "DUMMY"
        FROM (SELECT "store_id"
        FROM "foodmart"."sales_fact_1997") AS "t" "
        INNER JOIN (SELECT "store_id"
        FROM "foodmart"."sales_fact_1997") AS "t0"
        ON "t"."store_id" = "t0"."store_id") AS "t1""

        OutOfMemoryStackTrace:
        JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError".
        java.sql.SQLException: java.lang.OutOfMemoryError: Java heap space
        at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
        at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
        at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
        at org.hsqldb.jdbc.JDBCStatement.executeQuery(Unknown Source)
        at org.apache.calcite.jdbc.JayTestFoodMartHSQL.testStatement(JayTestFoodMartHSQL.java:43)
        at org.apache.calcite.jdbc.JayTestFoodMartHSQL.main(JayTestFoodMartHSQL.java:29)
        Caused by: org.hsqldb.HsqlException: java.lang.OutOfMemoryError: Java heap space
        at org.hsqldb.error.Error.error(Unknown Source)
        at org.hsqldb.result.Result.newErrorResult(Unknown Source)
        at org.hsqldb.StatementDMQL.execute(Unknown Source)
        at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
        at org.hsqldb.Session.executeDirectStatement(Unknown Source)
        at org.hsqldb.Session.execute(Unknown Source)
        ... 4 more
        Caused by: java.lang.OutOfMemoryError: Java heap space
        at org.hsqldb.QuerySpecification.buildResult(Unknown Source)
        at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source)
        at org.hsqldb.QuerySpecification.getResult(Unknown Source)
        at org.hsqldb.TableDerived.materialise(Unknown Source)
        at org.hsqldb.StatementDMQL.materializeSubQueries(Unknown Source)

        Test Code:
        package org.apache.calcite.jdbc;

        import java.sql.Connection;
        import java.sql.DriverManager;
        import java.sql.ResultSet;

        public class JayTestFoodMartHSQL {

        private static Connection connection;
        public static void main(String[] args) {
        try

        { connection = DriverManager.getConnection( "jdbc:hsqldb:res:foodmart", "FOODMART", "FOODMART"); ResultSet rs = connection.createStatement().executeQuery("SELECT COUNT(*) AS \"C\" " + " FROM (SELECT 0 AS \"DUMMY\" " + "FROM (SELECT \"store_id\" " + "FROM \"foodmart\".\"sales_fact_1997\") AS \"t\" " + "INNER JOIN (SELECT \"store_id\" " + "FROM \"foodmart\".\"sales_fact_1997\") AS \"t0\" ON \"t\".\"store_id\" = \"t0\".\"store_id\") AS \"t1\""); rs.next(); System.out.println("Count is " + rs.getInt(1)); rs.close(); connection.close(); }

        catch (Exception e)

        { e.printStackTrace(); }

        }
        }

        Show
        jiunnjye Ng Jiunn Jye added a comment - Found the problem. For your information. I have rerun with EnumerableJoinRule disabled (removing from CalcitePrepareImpl). The JVM still crash with OOM error. After breaking down the test suite and run them one by one, managed to identify the failure at JdbcTest.testSelfJoinCount introduced by CALCITE-70 . The JdbcJoin has pushed the join operation to HSQL and the query blew up HSQL. This can be simulated by executing query on HSQL thus showing it is a HSQL issues. I will modify the test to run against a smaller table. Test Query : select count as c from "foodmart"."sales_fact_1997" as p1 join "foodmart"."sales_fact_1997" as p2 using ("store_id") Generated Query after JdbcJoin: SELECT COUNT AS "C" FROM (SELECT 0 AS "DUMMY" FROM (SELECT "store_id" FROM "foodmart"."sales_fact_1997") AS "t" " INNER JOIN (SELECT "store_id" FROM "foodmart"."sales_fact_1997") AS "t0" ON "t"."store_id" = "t0"."store_id") AS "t1"" OutOfMemoryStackTrace: JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError". java.sql.SQLException: java.lang.OutOfMemoryError: Java heap space at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source) at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source) at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source) at org.hsqldb.jdbc.JDBCStatement.executeQuery(Unknown Source) at org.apache.calcite.jdbc.JayTestFoodMartHSQL.testStatement(JayTestFoodMartHSQL.java:43) at org.apache.calcite.jdbc.JayTestFoodMartHSQL.main(JayTestFoodMartHSQL.java:29) Caused by: org.hsqldb.HsqlException: java.lang.OutOfMemoryError: Java heap space at org.hsqldb.error.Error.error(Unknown Source) at org.hsqldb.result.Result.newErrorResult(Unknown Source) at org.hsqldb.StatementDMQL.execute(Unknown Source) at org.hsqldb.Session.executeCompiledStatement(Unknown Source) at org.hsqldb.Session.executeDirectStatement(Unknown Source) at org.hsqldb.Session.execute(Unknown Source) ... 4 more Caused by: java.lang.OutOfMemoryError: Java heap space at org.hsqldb.QuerySpecification.buildResult(Unknown Source) at org.hsqldb.QuerySpecification.getSingleResult(Unknown Source) at org.hsqldb.QuerySpecification.getResult(Unknown Source) at org.hsqldb.TableDerived.materialise(Unknown Source) at org.hsqldb.StatementDMQL.materializeSubQueries(Unknown Source) Test Code: package org.apache.calcite.jdbc; import java.sql.Connection; import java.sql.DriverManager; import java.sql.ResultSet; public class JayTestFoodMartHSQL { private static Connection connection; public static void main(String[] args) { try { connection = DriverManager.getConnection( "jdbc:hsqldb:res:foodmart", "FOODMART", "FOODMART"); ResultSet rs = connection.createStatement().executeQuery("SELECT COUNT(*) AS \"C\" " + " FROM (SELECT 0 AS \"DUMMY\" " + "FROM (SELECT \"store_id\" " + "FROM \"foodmart\".\"sales_fact_1997\") AS \"t\" " + "INNER JOIN (SELECT \"store_id\" " + "FROM \"foodmart\".\"sales_fact_1997\") AS \"t0\" ON \"t\".\"store_id\" = \"t0\".\"store_id\") AS \"t1\""); rs.next(); System.out.println("Count is " + rs.getInt(1)); rs.close(); connection.close(); } catch (Exception e) { e.printStackTrace(); } } }
        Hide
        jiunnjye Ng Jiunn Jye added a comment - - edited

        Patch "CALCITE-631-PushThetaJoinsDownToJDBCAdapter.patch" attached. This resolve the Test Suite OutOfMemory Issue and failed LaticeTest.TestJG.

        Patch contain the following changes.

        • New method JdbcRules.JdbcJoinRules.validateCondition to check if condition can be converted into SqlJoin
        • New method JdbcRules.JdbcJoin.convertConditionToSqlNode for convert join condition in RexCall into SqlNode
        • Update JdbcRules.JdbcJoin.getRows() to return max of leftRowCount,rightRowCount from (leftRowCount * rightRowCount)
        • Update JdbcRules.JdbcJoin.implement() to construct SqlJoin from
          condition RexNode
        • JoinInfo is not longer required in JdbcJoin and JdbcJoinRules.
        • Add new TestCases on JdbcJoin in JdbcAdapterTest
        • Add SCOTT_MODEL into JdbcTest.
        • Update JdbcTest.testSelfJoinCount to select from smaller table to avoid HSQL OutOfMemoryException when processing query
        • Update LaticeTest.TestJG with new plan using JdbcJoin
        Show
        jiunnjye Ng Jiunn Jye added a comment - - edited Patch " CALCITE-631 -PushThetaJoinsDownToJDBCAdapter.patch" attached. This resolve the Test Suite OutOfMemory Issue and failed LaticeTest.TestJG. Patch contain the following changes. New method JdbcRules.JdbcJoinRules.validateCondition to check if condition can be converted into SqlJoin New method JdbcRules.JdbcJoin.convertConditionToSqlNode for convert join condition in RexCall into SqlNode Update JdbcRules.JdbcJoin.getRows() to return max of leftRowCount,rightRowCount from (leftRowCount * rightRowCount) Update JdbcRules.JdbcJoin.implement() to construct SqlJoin from condition RexNode JoinInfo is not longer required in JdbcJoin and JdbcJoinRules. Add new TestCases on JdbcJoin in JdbcAdapterTest Add SCOTT_MODEL into JdbcTest. Update JdbcTest.testSelfJoinCount to select from smaller table to avoid HSQL OutOfMemoryException when processing query Update LaticeTest.TestJG with new plan using JdbcJoin
        Hide
        julianhyde Julian Hyde added a comment -

        Before I review this patch... Does your patch cause substantially more tests to run in the JDBC data source rather than in-memory collections? Does the test suite run any slower? If so, I won't accept it. The purpose of the test suite is to test Calcite, and it needs to be fast.

        Show
        julianhyde Julian Hyde added a comment - Before I review this patch... Does your patch cause substantially more tests to run in the JDBC data source rather than in-memory collections? Does the test suite run any slower? If so, I won't accept it. The purpose of the test suite is to test Calcite, and it needs to be fast.
        Hide
        jiunnjye Ng Jiunn Jye added a comment -

        I have added 9 test cases to run in JDBC data source.

        The test suite did not run any slower. Below are the reactor summary before and after the patch

        #############
        Before Patch
        #############
        [INFO] Reactor Summary:
        [INFO]
        [INFO] Calcite ............................................ SUCCESS [ 7.558 s]
        [INFO] Calcite Avatica .................................... SUCCESS [ 6.597 s]
        [INFO] Calcite Avatica Server ............................. SUCCESS [ 0.676 s]
        [INFO] Calcite Linq4j ..................................... SUCCESS [ 2.818 s]
        [INFO] Calcite Core ....................................... SUCCESS [02:38 min]
        [INFO] Calcite Examples ................................... SUCCESS [ 0.299 s]
        [INFO] Calcite Example CSV ................................ SUCCESS [ 5.874 s]
        [INFO] Calcite MongoDB .................................... SUCCESS [ 1.890 s]
        [INFO] Calcite Plus ....................................... SUCCESS [ 2.306 s]
        [INFO] Calcite Spark ...................................... SUCCESS [ 1.891 s]
        [INFO] Calcite Splunk ..................................... SUCCESS [ 1.490 s]
        [INFO] Calcite Ubenchmark ................................. SUCCESS [ 0.801 s]
        [INFO] ------------------------------------------------------------------------

        #############
        After Patch
        #############
        [INFO] Reactor Summary:
        [INFO]
        [INFO] Calcite ............................................ SUCCESS [ 3.440 s]
        [INFO] Calcite Avatica .................................... SUCCESS [ 3.758 s]
        [INFO] Calcite Avatica Server ............................. SUCCESS [ 0.490 s]
        [INFO] Calcite Linq4j ..................................... SUCCESS [ 2.305 s]
        [INFO] Calcite Core ....................................... SUCCESS [02:02 min]
        [INFO] Calcite Examples ................................... SUCCESS [ 0.455 s]
        [INFO] Calcite Example CSV ................................ SUCCESS [ 5.302 s]
        [INFO] Calcite MongoDB .................................... SUCCESS [ 1.854 s]
        [INFO] Calcite Plus ....................................... SUCCESS [ 2.574 s]
        [INFO] Calcite Spark ...................................... SUCCESS [ 7.792 s]
        [INFO] Calcite Splunk ..................................... SUCCESS [ 1.559 s]
        [INFO] Calcite Ubenchmark ................................. SUCCESS [ 1.099 s]

        Show
        jiunnjye Ng Jiunn Jye added a comment - I have added 9 test cases to run in JDBC data source. The test suite did not run any slower. Below are the reactor summary before and after the patch ############# Before Patch ############# [INFO] Reactor Summary: [INFO] [INFO] Calcite ............................................ SUCCESS [ 7.558 s] [INFO] Calcite Avatica .................................... SUCCESS [ 6.597 s] [INFO] Calcite Avatica Server ............................. SUCCESS [ 0.676 s] [INFO] Calcite Linq4j ..................................... SUCCESS [ 2.818 s] [INFO] Calcite Core ....................................... SUCCESS [02:38 min] [INFO] Calcite Examples ................................... SUCCESS [ 0.299 s] [INFO] Calcite Example CSV ................................ SUCCESS [ 5.874 s] [INFO] Calcite MongoDB .................................... SUCCESS [ 1.890 s] [INFO] Calcite Plus ....................................... SUCCESS [ 2.306 s] [INFO] Calcite Spark ...................................... SUCCESS [ 1.891 s] [INFO] Calcite Splunk ..................................... SUCCESS [ 1.490 s] [INFO] Calcite Ubenchmark ................................. SUCCESS [ 0.801 s] [INFO] ------------------------------------------------------------------------ ############# After Patch ############# [INFO] Reactor Summary: [INFO] [INFO] Calcite ............................................ SUCCESS [ 3.440 s] [INFO] Calcite Avatica .................................... SUCCESS [ 3.758 s] [INFO] Calcite Avatica Server ............................. SUCCESS [ 0.490 s] [INFO] Calcite Linq4j ..................................... SUCCESS [ 2.305 s] [INFO] Calcite Core ....................................... SUCCESS [02:02 min] [INFO] Calcite Examples ................................... SUCCESS [ 0.455 s] [INFO] Calcite Example CSV ................................ SUCCESS [ 5.302 s] [INFO] Calcite MongoDB .................................... SUCCESS [ 1.854 s] [INFO] Calcite Plus ....................................... SUCCESS [ 2.574 s] [INFO] Calcite Spark ...................................... SUCCESS [ 7.792 s] [INFO] Calcite Splunk ..................................... SUCCESS [ 1.559 s] [INFO] Calcite Ubenchmark ................................. SUCCESS [ 1.099 s]
        Show
        julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/a13137dc .
        Hide
        julianhyde Julian Hyde added a comment -

        Resolved in release 1.2.0-incubating (2015-04-16)

        Show
        julianhyde Julian Hyde added a comment - Resolved in release 1.2.0-incubating (2015-04-16)

          People

          • Assignee:
            julianhyde Julian Hyde
            Reporter:
            jiunnjye Ng Jiunn Jye
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development