[ https://issues.apache.org/jira/browse/CALCITE-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16985947#comment-16985947 ]
Ruben Q L edited comment on CALCITE-3535 at 12/2/19 12:34 PM: -------------------------------------------------------------- We had some problems in the past with test parallelization in maven: [https://lists.apache.org/thread.html/d9205b98873d60102ed53e46ffde2fa63632eeca948ee1c9ab810827@%3Cdev.calcite.apache.org%3E] Perhaps there might be similar issues with gradle? After some try an error, I can confirm that the issue seems to be located on {{UtilTest#testRelBuilderExample}}, only when running with gradle. This test (like many others) uses {{RelBuilderTest.config()}} to build its FrameworkConfig. This is what I have found out that solve / does not solve the issue (I am new with gradle, so I don't know if some of the options I tried make sense at all): *What does not solve the issue:* - Modifying {{org.gradle.parallel}} and/or {{kotlin.parallel.tasks.in.project}} in gradle.properties file - Using '{{no-parallel}}' or '{{max-workers 1}}' command line options *What does "solve" the issue:* - Tagging UtilTest#testRelBuilderExample with {{@Ignore}} - Running only example0 (which does not run any scan) in RelBuilderExample#runAllExamples (i.e. do not run examples1,2,3,4 which actually execute scan) Apart from that, without knowing the root cause of the issue, I wonder if we should even run {{UtilTest#testRelBuilderExample}} in the first place, since this is not a real unit tests (it just builds several plans using a RelBuilder, and then prints them; and in our case it does not even print because it is executed with {{verbose=false}}: {code} public class UtilTest { ... @Test public void testRelBuilderExample() { new RelBuilderExample(false).runAllExamples(); } {code} was (Author: rubenql): We had some problems in the past with test parallelization in maven: [https://lists.apache.org/thread.html/d9205b98873d60102ed53e46ffde2fa63632eeca948ee1c9ab810827@%3Cdev.calcite.apache.org%3E] Perhaps there might be similar issues with gradle? After some try an error, I can confirm that the issue seems to be located on {{UtilTest#testRelBuilderExample}}, only when running with gradle. This test (like many others) uses {{RelBuilderTest.config()}} to build its FrameworkConfig. This is what I have found out that solve / does not solve the issue (I am new with gradle, so I don't know if some of the options I tried make sense at all): *What does not solve the issue:* - Modifying {{org.gradle.parallel}} and/or {{kotlin.parallel.tasks.in.project}} in gradle.properties file - Using '{{no-parallel}}' or '{{max-workers 1}}' command line options *What does "solve" the issue:* - Tagging UtilTest#testRelBuilderExample with {{@Ignore}} - Running only example0 (which does not run any scan) in RelBuilderExample#runAllExamples (i.e. do not run examples1,2,3,4 which actually execute scan) > EnumerableJoinRule: remove unnecessary Filter on top of INNER Join > ------------------------------------------------------------------ > > Key: CALCITE-3535 > URL: https://issues.apache.org/jira/browse/CALCITE-3535 > Project: Calcite > Issue Type: Task > Components: core > Affects Versions: 1.21.0 > Reporter: Ruben Q L > Assignee: Ruben Q L > Priority: Minor > Labels: pull-request-available > Fix For: 1.22.0 > > Attachments: threadDump.txt > > Time Spent: 20m > Remaining Estimate: 0h > > With the implementation of CALCITE-2973, now EnumerableHashJoin supports all > type of conditions (not just equi joins). However, there is still one > [TODO|https://github.com/apache/calcite/blob/07c1efbb2b42a0e27f9d01968d357d9c1e17cd51/core/src/main/java/org/apache/calcite/adapter/enumerable/EnumerableJoinRule.java#L89] > in EnumerableHashJoinRule that, in case of an INNER Join, creates a Filter > with the non-equi conditions on top of the EnumerableHashJoin (created only > with the equi-conditions), this filter is not really needed, since now > EnumerableHashJoinRule can support the full condition: equi and non-equi > items. -- This message was sent by Atlassian Jira (v8.3.4#803005)