[jira] [Resolved] (CALCITE-3361) Add a test that parses and validates a SQL statement with every built-in Redshift function
[ https://issues.apache.org/jira/browse/CALCITE-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-3361. -- Fix Version/s: 1.22.0 Resolution: Fixed Fixed in [35c5f57d|https://github.com/apache/calcite/commit/35c5f57d7db2b4745086178602ca69195ffb858e]. > Add a test that parses and validates a SQL statement with every built-in > Redshift function > -- > > Key: CALCITE-3361 > URL: https://issues.apache.org/jira/browse/CALCITE-3361 > Project: Calcite > Issue Type: Bug >Reporter: Julian Hyde >Priority: Major > Fix For: 1.22.0 > > > Add a test that parses and validates a SQL statement with every built-in > Redshift function. > It would be part of the babel component, but would go beyond parsing, and > also validate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3388) StackOverflowError for creating structured RelDataType from class type
[
https://issues.apache.org/jira/browse/CALCITE-3388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3388:
Labels: pull-request-available (was: )
> StackOverflowError for creating structured RelDataType from class type
> --
>
> Key: CALCITE-3388
> URL: https://issues.apache.org/jira/browse/CALCITE-3388
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Minor
> Labels: pull-request-available
>
> When creating a structured RelDataType from a java type with recursion
> reference,
> StackOverflowError occurs, full stack trace
>
> {noformat}
> java.lang.StackOverflowError
> at java.lang.Class.privateGetPublicFields(Class.java:2600)
> at java.lang.Class.getFields(Class.java:1557)
> at
> org.apache.calcite.rel.type.RelDataTypeFactoryImpl.fieldsOf(RelDataTypeFactoryImpl.java:440)
> at
> org.apache.calcite.rel.type.RelDataTypeFactoryImpl.access$700(RelDataTypeFactoryImpl.java:50)
> at
> org.apache.calcite.rel.type.RelDataTypeFactoryImpl$JavaType.(RelDataTypeFactoryImpl.java:568)
> at
> org.apache.calcite.rel.type.RelDataTypeFactoryImpl$JavaType.(RelDataTypeFactoryImpl.java:560)
> at
> org.apache.calcite.rel.type.RelDataTypeFactoryImpl$JavaType.(RelDataTypeFactoryImpl.java:554)
> at
> org.apache.calcite.rel.type.RelDataTypeFactoryImpl.createJavaType(RelDataTypeFactoryImpl.java:120)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:143)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:158)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:158)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:158)
> at
> org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
> {noformat}
> Add the test case in JavaTypeFactoryTest to reproduce the exception
> {noformat}
> /***/
> private static class RecursionStruct {
> public Integer intField;
> public RecursionStruct next;
> }
> /***/
> private static class RecursionStruct1 {
> public Integer intField;
> public RecursionStruct2 struct2;
> }
> /***/
> private static class RecursionStruct2 {
> public Integer intField;
> public RecursionStruct1 struct1;
> }
> @Test public void testRecursion() {
> TYPE_FACTORY.createStructType(RecursionStruct.class);
> TYPE_FACTORY.createStructType(RecursionStruct1.class);
> }
> {noformat}
>
> Better to check for recursion and throw an exception explicitly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3388) StackOverflowError for creating structured RelDataType from class type
Wang Yanlin created CALCITE-3388:
Summary: StackOverflowError for creating structured RelDataType
from class type
Key: CALCITE-3388
URL: https://issues.apache.org/jira/browse/CALCITE-3388
Project: Calcite
Issue Type: Bug
Reporter: Wang Yanlin
When creating a structured RelDataType from a java type with recursion
reference,
StackOverflowError occurs, full stack trace
{noformat}
java.lang.StackOverflowError
at java.lang.Class.privateGetPublicFields(Class.java:2600)
at java.lang.Class.getFields(Class.java:1557)
at
org.apache.calcite.rel.type.RelDataTypeFactoryImpl.fieldsOf(RelDataTypeFactoryImpl.java:440)
at
org.apache.calcite.rel.type.RelDataTypeFactoryImpl.access$700(RelDataTypeFactoryImpl.java:50)
at
org.apache.calcite.rel.type.RelDataTypeFactoryImpl$JavaType.(RelDataTypeFactoryImpl.java:568)
at
org.apache.calcite.rel.type.RelDataTypeFactoryImpl$JavaType.(RelDataTypeFactoryImpl.java:560)
at
org.apache.calcite.rel.type.RelDataTypeFactoryImpl$JavaType.(RelDataTypeFactoryImpl.java:554)
at
org.apache.calcite.rel.type.RelDataTypeFactoryImpl.createJavaType(RelDataTypeFactoryImpl.java:120)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:143)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:158)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:158)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createType(JavaTypeFactoryImpl.java:158)
at
org.apache.calcite.jdbc.JavaTypeFactoryImpl.createStructType(JavaTypeFactoryImpl.java:82)
{noformat}
Add the test case in JavaTypeFactoryTest to reproduce the exception
{noformat}
/***/
private static class RecursionStruct {
public Integer intField;
public RecursionStruct next;
}
/***/
private static class RecursionStruct1 {
public Integer intField;
public RecursionStruct2 struct2;
}
/***/
private static class RecursionStruct2 {
public Integer intField;
public RecursionStruct1 struct1;
}
@Test public void testRecursion() {
TYPE_FACTORY.createStructType(RecursionStruct.class);
TYPE_FACTORY.createStructType(RecursionStruct1.class);
}
{noformat}
Better to check for recursion and throw an exception explicitly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2792) Stackoverflow while evaluating filter with large number of OR conditions
[
https://issues.apache.org/jira/browse/CALCITE-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944937#comment-16944937
]
Haisheng Yuan commented on CALCITE-2792:
The reason of stackoverflow for large ORs is the left deep binary tree, we need
to change it to balanced binary tree, to reduce the depth of the call. I opened
a pull request, please take a look.
> 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
>Priority: Major
> Labels: pull-request-available
> Attachments: calcite-stackoverflow.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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
[jira] [Updated] (CALCITE-2792) Stackoverflow while evaluating filter with large number of OR conditions
[
https://issues.apache.org/jira/browse/CALCITE-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-2792:
Labels: pull-request-available (was: )
> 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
>Priority: Major
> Labels: pull-request-available
> Attachments: calcite-stackoverflow.zip
>
>
> 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
>
[jira] [Commented] (CALCITE-3387) Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is ambiguous" error
[
https://issues.apache.org/jira/browse/CALCITE-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944926#comment-16944926
]
Julian Hyde commented on CALCITE-3387:
--
Here is a test case:
{noformat}
diff --git a/core/src/test/resources/sql/join.iq
b/core/src/test/resources/sql/join.iq
index 18fc8f5c3..bcbe54cf9 100644
--- a/core/src/test/resources/sql/join.iq
+++ b/core/src/test/resources/sql/join.iq
@@ -172,6 +172,38 @@ group by cube(emp.deptno, dept.deptno);
!ok
+# [CALCITE-3387] Query with GROUP BY and JOIN ... USING wrongly fails with
+# "Column 'DEPTNO' is ambiguous" error
+select deptno, count(*)
+from "scott".emp
+join "scott".dept using (deptno)
+group by deptno;
+!ok
+
+# Similar, with GROUPING SETS and GROUPING
+select deptno, grouping(deptno), grouping(deptno, job), count(*)
+from "scott".emp
+join "scott".dept using (deptno)
+group by grouping sets ((deptno), (deptno, job));
+!ok
+
+# For this query, Oracle gives
+# ORA-25154: column part of USING clause cannot have qualifier
+# and Calcite should too.
+select dept.deptno, count(*)
+from "scott".emp
+join "scott".dept using (deptno);
+column part of USING clause cannot have qualifier
+!error
+
+# Ditto
+select count(*)
+from "scott".emp
+join "scott".dept using (deptno)
+group by dept.deptno;
+column part of USING clause cannot have qualifier
+!error
+
# [CALCITE-688] splitCondition does not behave correctly
# when one side of the condition references columns from
# different inputs
{noformat}
> Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is
> ambiguous" error
> --
>
> Key: CALCITE-3387
> URL: https://issues.apache.org/jira/browse/CALCITE-3387
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is
> ambiguous" error. Here is the query:
> {code}
> select deptno, count(*)
> from emp
> join dept using (deptno)
> group by deptno;
> {code}
> Because of USING, the two deptno fields should be merged into one, and
> therefore {{deptno}} is not ambiguous. That query works in Oracle. Also note
> that
> {code}select deptno
> from emp
> join dept using (deptno)
> {code}
> works correctly in Calcite, and has since CALCITE-2227 was fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3386) CyclicMetadataException gives misleading stack trace
[
https://issues.apache.org/jira/browse/CALCITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3386:
Labels: pull-request-available (was: )
> CyclicMetadataException gives misleading stack trace
>
>
> Key: CALCITE-3386
> URL: https://issues.apache.org/jira/browse/CALCITE-3386
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Zuozhi Wang
>Priority: Major
> Labels: pull-request-available
>
> Calcite currently reuses the same instance when throwing
> CyclicMetadataException as shown below.
> {code:java}
> /** Singleton instance. Since this exception is thrown for signaling
> purposes, * rather than on an actual error, re-using a singleton instance
> saves the * effort of constructing an exception instance. */
> @SuppressWarnings("ThrowableInstanceNeverThrown")
> public static final CyclicMetadataException INSTANCE = new
> CyclicMetadataException();
> {code}
>
> Reusing the same exception instance gives the wrong stack trace, see:
> [https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
> The misleading stack trace causes many confusions when debugging. The
> potential performance impact because of object construction is minor compared
> to the time spent on debugging. Therefore it should be changed to not reuse
> the singleton instance.
> A pull request have been opened to fix this issue:
> [https://github.com/apache/calcite/pull/1484]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3386) CyclicMetadataException gives misleading stack trace
[
https://issues.apache.org/jira/browse/CALCITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944862#comment-16944862
]
Haisheng Yuan commented on CALCITE-3386:
Agree
> CyclicMetadataException gives misleading stack trace
>
>
> Key: CALCITE-3386
> URL: https://issues.apache.org/jira/browse/CALCITE-3386
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Zuozhi Wang
>Priority: Major
>
> Calcite currently reuses the same instance when throwing
> CyclicMetadataException as shown below.
> {code:java}
> /** Singleton instance. Since this exception is thrown for signaling
> purposes, * rather than on an actual error, re-using a singleton instance
> saves the * effort of constructing an exception instance. */
> @SuppressWarnings("ThrowableInstanceNeverThrown")
> public static final CyclicMetadataException INSTANCE = new
> CyclicMetadataException();
> {code}
>
> Reusing the same exception instance gives the wrong stack trace, see:
> [https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
> The misleading stack trace causes many confusions when debugging. The
> potential performance impact because of object construction is minor compared
> to the time spent on debugging. Therefore it should be changed to not reuse
> the singleton instance.
> A pull request have been opened to fix this issue:
> [https://github.com/apache/calcite/pull/1484]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3387) Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is ambiguous" error
Julian Hyde created CALCITE-3387:
Summary: Query with GROUP BY and JOIN ... USING wrongly fails with
"Column 'DEPTNO' is ambiguous" error
Key: CALCITE-3387
URL: https://issues.apache.org/jira/browse/CALCITE-3387
Project: Calcite
Issue Type: Bug
Reporter: Julian Hyde
Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is
ambiguous" error. Here is the query:
{code}
select deptno, count(*)
from emp
join dept using (deptno)
group by deptno;
{code}
Because of USING, the two deptno fields should be merged into one, and
therefore {{deptno}} is not ambiguous. That query works in Oracle. Also note
that
{code}select deptno
from emp
join dept using (deptno)
{code}
works correctly, and has since CALCITE-2227 was fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3387) Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is ambiguous" error
[
https://issues.apache.org/jira/browse/CALCITE-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-3387:
-
Description:
Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is
ambiguous" error. Here is the query:
{code}
select deptno, count(*)
from emp
join dept using (deptno)
group by deptno;
{code}
Because of USING, the two deptno fields should be merged into one, and
therefore {{deptno}} is not ambiguous. That query works in Oracle. Also note
that
{code}select deptno
from emp
join dept using (deptno)
{code}
works correctly in Calcite, and has since CALCITE-2227 was fixed.
was:
Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is
ambiguous" error. Here is the query:
{code}
select deptno, count(*)
from emp
join dept using (deptno)
group by deptno;
{code}
Because of USING, the two deptno fields should be merged into one, and
therefore {{deptno}} is not ambiguous. That query works in Oracle. Also note
that
{code}select deptno
from emp
join dept using (deptno)
{code}
works correctly, and has since CALCITE-2227 was fixed.
> Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is
> ambiguous" error
> --
>
> Key: CALCITE-3387
> URL: https://issues.apache.org/jira/browse/CALCITE-3387
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Query with GROUP BY and JOIN ... USING wrongly fails with "Column 'DEPTNO' is
> ambiguous" error. Here is the query:
> {code}
> select deptno, count(*)
> from emp
> join dept using (deptno)
> group by deptno;
> {code}
> Because of USING, the two deptno fields should be merged into one, and
> therefore {{deptno}} is not ambiguous. That query works in Oracle. Also note
> that
> {code}select deptno
> from emp
> join dept using (deptno)
> {code}
> works correctly in Calcite, and has since CALCITE-2227 was fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3386) CyclicMetadataException gives misleading stack trace
[
https://issues.apache.org/jira/browse/CALCITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zuozhi Wang updated CALCITE-3386:
-
Description:
Calcite currently reuses the same instance when throwing
CyclicMetadataException as shown below.
{code:java}
/** Singleton instance. Since this exception is thrown for signaling purposes,
* rather than on an actual error, re-using a singleton instance saves the *
effort of constructing an exception instance. */
@SuppressWarnings("ThrowableInstanceNeverThrown")
public static final CyclicMetadataException INSTANCE = new
CyclicMetadataException();
{code}
Reusing the same exception instance gives the wrong stack trace, see:
[https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
The misleading stack trace causes many confusions when debugging. The potential
performance impact because of object construction is minor compared to the
spent on debugging. Therefore it should be changed to not reuse the singleton
instance.
A pull request have been opened to fix this issue:
[https://github.com/apache/calcite/pull/1484]
was:
Calcite currently reuses the same instance when throwing
CyclicMetadataException as shown below.
{code:java}
/** Singleton instance. Since this exception is thrown for signaling purposes,
* rather than on an actual error, re-using a singleton instance saves the *
effort of constructing an exception instance. */
@SuppressWarnings("ThrowableInstanceNeverThrown")
public static final CyclicMetadataException INSTANCE = new
CyclicMetadataException();
{code}
Reusing the same exception instance gives the wrong stack trace, see:
[https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
The misleading stack trace causes many confusions when debugging. The potential
performance impact because of object construction is minor compared to the
spent on debugging. Therefore it should be changed to not reuse the singleton
instance.
A pull request have been opened to fix this issue:
[https://github.com/apache/calcite/pull/1484/files]
> CyclicMetadataException gives misleading stack trace
>
>
> Key: CALCITE-3386
> URL: https://issues.apache.org/jira/browse/CALCITE-3386
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Zuozhi Wang
>Priority: Major
>
> Calcite currently reuses the same instance when throwing
> CyclicMetadataException as shown below.
> {code:java}
> /** Singleton instance. Since this exception is thrown for signaling
> purposes, * rather than on an actual error, re-using a singleton instance
> saves the * effort of constructing an exception instance. */
> @SuppressWarnings("ThrowableInstanceNeverThrown")
> public static final CyclicMetadataException INSTANCE = new
> CyclicMetadataException();
> {code}
>
> Reusing the same exception instance gives the wrong stack trace, see:
> [https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
> The misleading stack trace causes many confusions when debugging. The
> potential performance impact because of object construction is minor compared
> to the spent on debugging. Therefore it should be changed to not reuse the
> singleton instance.
> A pull request have been opened to fix this issue:
> [https://github.com/apache/calcite/pull/1484]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3386) CyclicMetadataException gives misleading stack trace
[
https://issues.apache.org/jira/browse/CALCITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zuozhi Wang updated CALCITE-3386:
-
Description:
Calcite currently reuses the same instance when throwing
CyclicMetadataException as shown below.
{code:java}
/** Singleton instance. Since this exception is thrown for signaling purposes,
* rather than on an actual error, re-using a singleton instance saves the *
effort of constructing an exception instance. */
@SuppressWarnings("ThrowableInstanceNeverThrown")
public static final CyclicMetadataException INSTANCE = new
CyclicMetadataException();
{code}
Reusing the same exception instance gives the wrong stack trace, see:
[https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
The misleading stack trace causes many confusions when debugging. The potential
performance impact because of object construction is minor compared to the time
spent on debugging. Therefore it should be changed to not reuse the singleton
instance.
A pull request have been opened to fix this issue:
[https://github.com/apache/calcite/pull/1484]
was:
Calcite currently reuses the same instance when throwing
CyclicMetadataException as shown below.
{code:java}
/** Singleton instance. Since this exception is thrown for signaling purposes,
* rather than on an actual error, re-using a singleton instance saves the *
effort of constructing an exception instance. */
@SuppressWarnings("ThrowableInstanceNeverThrown")
public static final CyclicMetadataException INSTANCE = new
CyclicMetadataException();
{code}
Reusing the same exception instance gives the wrong stack trace, see:
[https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
The misleading stack trace causes many confusions when debugging. The potential
performance impact because of object construction is minor compared to the
spent on debugging. Therefore it should be changed to not reuse the singleton
instance.
A pull request have been opened to fix this issue:
[https://github.com/apache/calcite/pull/1484]
> CyclicMetadataException gives misleading stack trace
>
>
> Key: CALCITE-3386
> URL: https://issues.apache.org/jira/browse/CALCITE-3386
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Zuozhi Wang
>Priority: Major
>
> Calcite currently reuses the same instance when throwing
> CyclicMetadataException as shown below.
> {code:java}
> /** Singleton instance. Since this exception is thrown for signaling
> purposes, * rather than on an actual error, re-using a singleton instance
> saves the * effort of constructing an exception instance. */
> @SuppressWarnings("ThrowableInstanceNeverThrown")
> public static final CyclicMetadataException INSTANCE = new
> CyclicMetadataException();
> {code}
>
> Reusing the same exception instance gives the wrong stack trace, see:
> [https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
> The misleading stack trace causes many confusions when debugging. The
> potential performance impact because of object construction is minor compared
> to the time spent on debugging. Therefore it should be changed to not reuse
> the singleton instance.
> A pull request have been opened to fix this issue:
> [https://github.com/apache/calcite/pull/1484]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3386) CyclicMetadataException gives misleading stack trace
[
https://issues.apache.org/jira/browse/CALCITE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zuozhi Wang updated CALCITE-3386:
-
Description:
Calcite currently reuses the same instance when throwing
CyclicMetadataException as shown below.
{code:java}
/** Singleton instance. Since this exception is thrown for signaling purposes,
* rather than on an actual error, re-using a singleton instance saves the *
effort of constructing an exception instance. */
@SuppressWarnings("ThrowableInstanceNeverThrown")
public static final CyclicMetadataException INSTANCE = new
CyclicMetadataException();
{code}
Reusing the same exception instance gives the wrong stack trace, see:
[https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
The misleading stack trace causes many confusions when debugging. The potential
performance impact because of object construction is minor compared to the
spent on debugging. Therefore it should be changed to not reuse the singleton
instance.
A pull request have been opened to fix this issue:
[https://github.com/apache/calcite/pull/1484/files]
was:
Calcite currently reuses the same instance when throwing
CyclicMetadataException as shown below.
{code:java}
/** Singleton instance. Since this exception is thrown for signaling purposes,
* rather than on an actual error, re-using a singleton instance saves the *
effort of constructing an exception instance. */
@SuppressWarnings("ThrowableInstanceNeverThrown")
public static final CyclicMetadataException INSTANCE = new
CyclicMetadataException();
{code}
Reusing the same exception instance gives the wrong stack trace, see:
[https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
The misleading stack trace causes many confusions when debugging. The potential
performance impact because of object construction is minor compared to the
spent on debugging. Therefore it should be changed to not reuse the singleton
instance.
> CyclicMetadataException gives misleading stack trace
>
>
> Key: CALCITE-3386
> URL: https://issues.apache.org/jira/browse/CALCITE-3386
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Zuozhi Wang
>Priority: Major
>
> Calcite currently reuses the same instance when throwing
> CyclicMetadataException as shown below.
> {code:java}
> /** Singleton instance. Since this exception is thrown for signaling
> purposes, * rather than on an actual error, re-using a singleton instance
> saves the * effort of constructing an exception instance. */
> @SuppressWarnings("ThrowableInstanceNeverThrown")
> public static final CyclicMetadataException INSTANCE = new
> CyclicMetadataException();
> {code}
>
> Reusing the same exception instance gives the wrong stack trace, see:
> [https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
> The misleading stack trace causes many confusions when debugging. The
> potential performance impact because of object construction is minor compared
> to the spent on debugging. Therefore it should be changed to not reuse the
> singleton instance.
> A pull request have been opened to fix this issue:
> [https://github.com/apache/calcite/pull/1484/files]
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3386) CyclicMetadataException gives misleading stack trace
Zuozhi Wang created CALCITE-3386:
Summary: CyclicMetadataException gives misleading stack trace
Key: CALCITE-3386
URL: https://issues.apache.org/jira/browse/CALCITE-3386
Project: Calcite
Issue Type: Bug
Components: core
Reporter: Zuozhi Wang
Calcite currently reuses the same instance when throwing
CyclicMetadataException as shown below.
{code:java}
/** Singleton instance. Since this exception is thrown for signaling purposes,
* rather than on an actual error, re-using a singleton instance saves the *
effort of constructing an exception instance. */
@SuppressWarnings("ThrowableInstanceNeverThrown")
public static final CyclicMetadataException INSTANCE = new
CyclicMetadataException();
{code}
Reusing the same exception instance gives the wrong stack trace, see:
[https://stackoverflow.com/questions/15090664/is-it-safe-to-store-an-instance-of-an-exception-and-reuse-it]
The misleading stack trace causes many confusions when debugging. The potential
performance impact because of object construction is minor compared to the
spent on debugging. Therefore it should be changed to not reuse the singleton
instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset
[
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944646#comment-16944646
]
Xiening Dai edited comment on CALCITE-2018 at 10/4/19 4:28 PM:
---
The cyclic metadata exception is due to the change of memo that's caused by the
fix of CALCITE-2018. Actually this is a separate issue and we saw it in
different queries even before the fix. I don't think it is caused by the
validation. In the validation step, I choose to create a new RelMetadataQuery
object each time so it doesn't affect the cache of volcano planner in any way.
The only side effect I can see is the test running time could be extended due
to the extra validation steps (which is not cheap). But I think it worths it as
it catches any correctness and consistency issues of memo right the way.
was (Author: xndai):
The cyclic metadata exception is due to the change of memo that's caused by the
fix of CALCITE-2018. Actually this is a separate issue and we saw it in
different queries even before the fix. I don't think it relates to the
validation. In the validation step, I choose to create a new RelMetadataQuery
object each time so it doesn't affect the cache of volcano planner in any way.
The only side effect I can see is the test running time could be extended due
to the extra validation steps (which is not cheap). But I think it worths it as
it catches any correctness and consistency issues of memo right the way.
> Queries failed with AssertionError: rel has lower cost than best cost of
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Vova Vysotskyi
>Assignee: Danny Chen
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best
> cost of subset.
> Full stack trace for test
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
> has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
> at
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
[jira] [Commented] (CALCITE-2018) Queries failed with AssertionError: rel has lower cost than best cost of subset
[
https://issues.apache.org/jira/browse/CALCITE-2018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944646#comment-16944646
]
Xiening Dai commented on CALCITE-2018:
--
The cyclic metadata exception is due to the change of memo that's caused by the
fix of CALCITE-2018. Actually this is a separate issue and we saw it in
different queries even before the fix. I don't think it relates to the
validation. In the validation step, I choose to create a new RelMetadataQuery
object each time so it doesn't affect the cache of volcano planner in any way.
The only side effect I can see is the test running time could be extended due
to the extra validation steps (which is not cheap). But I think it worths it as
it catches any correctness and consistency issues of memo right the way.
> Queries failed with AssertionError: rel has lower cost than best cost of
> subset
> ---
>
> Key: CALCITE-2018
> URL: https://issues.apache.org/jira/browse/CALCITE-2018
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.13.0
>Reporter: Vova Vysotskyi
>Assignee: Danny Chen
>Priority: Critical
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> *Problem description*
> When rootLogger level is DEBUG, unit tests
> * MaterializationTest.testMaterializationSubstitution2
> * MaterializationTest.testJoinMaterializationUKFK8
> * MaterializationTest.testJoinMaterializationUKFK6
> * JdbcTest.testWhereNot
> unit tests are failed with error AssertionError: rel has lower cost than best
> cost of subset.
> Full stack trace for test
> {{MaterializationTest.testMaterializationSubstitution2}}:
> {noformat}
> java.lang.AssertionError: rel
> [rel#245:EnumerableUnion.ENUMERABLE.[](input#0=rel#246:Subset#5.ENUMERABLE.[],input#1=rel#239:Subset#6.ENUMERABLE.[0],all=true)]
> has lower cost {14.0 rows, 19.0 cpu, 0.0 io} than best cost {15.0 rows, 20.0
> cpu, 0.0 io} of subset [rel#243:Subset#7.ENUMERABLE.[]]
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.validate(VolcanoPlanner.java:906)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:866)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:101)
> at
> org.apache.calcite.rel.AbstractRelNode.onRegister(AbstractRelNode.java:336)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.registerImpl(VolcanoPlanner.java:1495)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.register(VolcanoPlanner.java:863)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:883)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.ensureRegistered(VolcanoPlanner.java:1766)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.transformTo(VolcanoRuleCall.java:135)
> at
> org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.FilterProjectTransposeRule.onMatch(FilterProjectTransposeRule.java:143)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:187)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:318)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:229)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at org.apache.calcite.schema.Schemas.prepare(Schemas.java:346)
> at
> org.apache.calcite.materialize.MaterializationService$DefaultTableFactory.createTable(MaterializationService.java:374)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:137)
> at
> org.apache.calcite.materialize.MaterializationService.defineMaterialization(MaterializationService.java:99)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:110)
> at
> org.apache.calcite.schema.impl.MaterializedViewTable$MaterializedViewTableMacro.(MaterializedViewTable.java:100)
>
[jira] [Closed] (CALCITE-3374) Error format check result for explain plan as json
[
https://issues.apache.org/jira/browse/CALCITE-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang Yanlin closed CALCITE-3374.
> Error format check result for explain plan as json
> --
>
> Key: CALCITE-3374
> URL: https://issues.apache.org/jira/browse/CALCITE-3374
> Project: Calcite
> Issue Type: Bug
>Reporter: Wang Yanlin
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The format check result of explain plan as json is incorrect, as
> {code:java}
> public boolean isJson() {
> return getFormat() == SqlExplainFormat.XML;
> }
> {code}
> in
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/SqlExplain.java#L174
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2970) Performance issue when enabling abstract converter for EnumerableConvertion
[
https://issues.apache.org/jira/browse/CALCITE-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16944334#comment-16944334
]
Stamatis Zampetakis commented on CALCITE-2970:
--
I'm with you [~hyuan], that was exactly my point. I asked for a profiling just
to verify that there is not something obvious that we can do. Apart from that
another way to mitigate the problem would be to restrict the scope of rules
(especially for rules matching logical and physical operators) and/or organize
the rule application in phases.
> Performance issue when enabling abstract converter for EnumerableConvertion
> ---
>
> Key: CALCITE-2970
> URL: https://issues.apache.org/jira/browse/CALCITE-2970
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: Haisheng Yuan
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> If we enable the use of abstract converter for {{EnumerableConvention}}, by
> making {{useAbstractConvertersForConversion}} return true,
> {{JDBCTest.testJoinManyWay}} will not complete.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
