[jira] [Created] (CALCITE-4126) Stackoverflow error when applying JoinCommuteRule

[Haisheng Yuan (Jira)]

Haisheng Yuan created CALCITE-4126:
--

 Summary: Stackoverflow error when applying JoinCommuteRule
 Key: CALCITE-4126
 URL: https://issues.apache.org/jira/browse/CALCITE-4126
 Project: Calcite
  Issue Type: Improvement
  Components: core
Reporter: Haisheng Yuan


Add the test case to RelOptRulesTest.java

{code:java}
  @Test void testJoinCommute() {
final HepProgram program = HepProgram.builder()
.addRuleInstance(JoinCommuteRule.INSTANCE)
.build();
final String sql = "select * \n"
+ "from sales.emp e join sales.dept d on e.empno > d.deptno";
sql(sql).with(program).check();
  }
{code}

Stacktrace:

{code:java}
java.lang.StackOverflowError
at org.apache.calcite.rex.RexInputRef.accept(RexInputRef.java:112)
at org.apache.calcite.rel.core.Project.isValid(Project.java:210)
at org.apache.calcite.rel.core.Project.(Project.java:90)
at 
org.apache.calcite.rel.logical.LogicalProject.(LogicalProject.java:67)
at 
org.apache.calcite.rel.logical.LogicalProject.copy(LogicalProject.java:128)
at 
org.apache.calcite.rel.logical.LogicalProject.copy(LogicalProject.java:45)
at org.apache.calcite.rel.core.Project.copy(Project.java:122)
at 
org.apache.calcite.plan.hep.HepPlanner.addRelToGraph(HepPlanner.java:803)
at 
org.apache.calcite.plan.hep.HepPlanner.applyTransformationResults(HepPlanner.java:732)
at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:543)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:360)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
at 
org.apache.calcite.plan.hep.HepPlanner.depthFirstApply(HepPlanner.java:372)
{code}

I check master branch and 1.23.0, both throw StackOverflowError.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CALCITE-3869) Stackoverflow with large OR statements

[Stephan Pirnbaum (Jira)]

Stephan Pirnbaum created CALCITE-3869:
-

 Summary: Stackoverflow with large OR statements
 Key: CALCITE-3869
 URL: https://issues.apache.org/jira/browse/CALCITE-3869
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.22.0
Reporter: Stephan Pirnbaum
 Attachments: stackoverflow.txt

As described in CALCITE-2792 large OR clauses lead to a StackOverflowError. 
While the ticket was closed with the remark "Resolved in release 1.22.0", the 
issue originally stated was not (completely) resolved. To reproduce this, I 
implemented following simple test case:
{code:java}
@Test
public void testLargeOr() {
  String orClause = IntStream.range(0, 1000).boxed()
 .map(i -> "e.\"empid\"=" + i)
 .collect(Collectors.joining(" OR "));
  final String sql = "SELECT * FROM \"hr\".\"emps\" e WHERE " + orClause;
  CalciteAssert.model(JdbcTest.HR_MODEL)
  .query(sql)
  .runs();
}{code}
 

The stackoverflow can be seen in the attached log.

As also CALCITE-2696 and CALCITE-2630 are not fixed, this is a blocking issue 
in our current use case.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CALCITE-2792) Stackoverflow while evaluating filter with large number of OR conditions

[Dirk Mahler (JIRA)]

Dirk Mahler created CALCITE-2792:


 Summary: Stackoverflow while evaluating filter with large number 
of OR conditions
 Key: CALCITE-2792
 URL: https://issues.apache.org/jira/browse/CALCITE-2792
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.18.0
Reporter: Dirk Mahler
Assignee: Julian Hyde


As a workaround for CALCITE-2696 we're currently using OR conditions for 
filtering values, e.g. instead of

{noformat}
... WHERE value2 IN (1,2,3)
{noformat}

{noformat}
... WHERE value2=1 OR value2=2 OR value2=3
{noformat}

We're now hitting a StackOverflowError because the number of values in the 
filter grows quite large (i.e. 1000-3000) and obviously the evaluation 
recursive:

{noformat}
java.lang.StackOverflowError
at java.util.AbstractCollection.toArray(AbstractCollection.java:176)
at 
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.(SqlShuttle.java:111)
at 
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:5699)
at 
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:50)
at 
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:33)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
at 
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
at 
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:865)
at 
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:5701)
at 
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:50)
at 
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:33)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
at 
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134)
at 
org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101)
at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:865)
at 
org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:5701)
at 
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:50)
at 
org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:33)
at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:138)
...
{noformat}

We tried to increase the stack size of the virtual machine (-Xss8000k) but this 
leads to a problem with Janino:

{noformat}
java.sql.SQLException: exception while executing query: Compiling "Buzz": Code 
of method 
"execute(Lorg/apache/calcite/interpreter/Context;[Ljava/lang/Object;)V" of 
class "Buzz" grows beyond 64 KB

at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
at 
org.apache.calcite.avatica.AvaticaConnection.executeQueryInternal(AvaticaConnection.java:577)
at 
org.apache.calcite.avatica.AvaticaPreparedStatement.executeQuery(AvaticaPreparedStatement.java:137)
at 
org.apache.calcite.issue.StackOverflowTest.stackOverflow(StackOverflowTest.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.a

Re: Calcite on StackOverflow

[Julian Hyde]

Yes, increasing activity on StackOverflow is good news indeed.

For what it’s worth, I think it’s well worth answering questions on SO. SO is 
better indexed, so an answer on SO is more likely to be found than an answer on 
an Apache mailing list. And the format (clear questions, voting up answers, and 
so forth) tends to produce useful knowledge.

As we’ve said before, writing code is not the only kind of contribution for 
which we would make someone a committer. If someone was active answering 
questions about Calcite on SO I would regard it as valuable community activity 
and I would be inclined to vote for them as a committer.

Julian


> On Mar 31, 2016, at 5:57 PM, Albert  wrote:
> 
> last time I was looking, think there were totally less than 5 questions or
> so. Trend is changing. ^^
> 
> On Thu, Mar 31, 2016 at 5:36 PM, Julian Hyde  wrote:
> 
>> Looking for ways to contribute to Calcite? There are a few questions
>> tagged “calcite” that do not yet have answers. It would be great if someone
>> could answer them.
>> 
>> http://stackoverflow.com/questions/tagged/calcite <
>> http://stackoverflow.com/questions/tagged/calcite>
>> 
>> Julian
>> 
>> 
> 
> 
> -- 
> ~~~
> no mistakes
> ~~

Re: Calcite on StackOverflow

[Albert]

last time I was looking, think there were totally less than 5 questions or
so. Trend is changing. ^^

On Thu, Mar 31, 2016 at 5:36 PM, Julian Hyde  wrote:

> Looking for ways to contribute to Calcite? There are a few questions
> tagged “calcite” that do not yet have answers. It would be great if someone
> could answer them.
>
> http://stackoverflow.com/questions/tagged/calcite <
> http://stackoverflow.com/questions/tagged/calcite>
>
> Julian
>
>


-- 
~~~
no mistakes
~~

Calcite on StackOverflow

[Julian Hyde]

Looking for ways to contribute to Calcite? There are a few questions tagged 
“calcite” that do not yet have answers. It would be great if someone could 
answer them.

http://stackoverflow.com/questions/tagged/calcite 


Julian