[jira] [Updated] (CALCITE-2311) case when returns redundant white space
[
https://issues.apache.org/jira/browse/CALCITE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2311:
Affects Version/s: (was: 1.1.0-incubating)
1.12.0
Fix Version/s: (was: 1.12.0)
1.17.0
> case when returns redundant white space
> ---
>
> Key: CALCITE-2311
> URL: https://issues.apache.org/jira/browse/CALCITE-2311
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> If the case-when expression has two branches which returns string
> literal,redundant white space will append to the short string literal after
> the ReduceExpressionsRule. For example:
> {code:java}
> case when id>0 then 'a' else 'abc' end{code}
> will actually be convert to
> {code:java}
> case when id>0 then 'a ' else 'abc' end{code}
>
> The reason is that the type of 'a' is CHAR(1),but CHAR(3) for 'abc',so the
> return type of the case-when is CHAR(3). The RexBuilder#ensureType() method
> append a cast convertion for 'a' to cast it to CHAR(3) type.The
> ReduceExpressionsRule execute the cast convertion which fill two whilte space
> to 'a'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2311) case when returns redundant white space
pengzhiwei created CALCITE-2311:
---
Summary: case when returns redundant white space
Key: CALCITE-2311
URL: https://issues.apache.org/jira/browse/CALCITE-2311
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.1.0-incubating
Reporter: pengzhiwei
Assignee: Julian Hyde
Fix For: 1.17.0
If case when has two brach which returns string literal,redundant white space
will append to the short brach.For example:
{code:java}
case when id>0 then 'a' else 'abc' end{code}
will actually be convert to
{code:java}
case when id>0 then 'a ' else 'abc' end{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2311) case when returns redundant white space
[
https://issues.apache.org/jira/browse/CALCITE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2311:
Fix Version/s: (was: 1.17.0)
1.12.0
> case when returns redundant white space
> ---
>
> Key: CALCITE-2311
> URL: https://issues.apache.org/jira/browse/CALCITE-2311
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.0-incubating
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.12.0
>
>
> If the case-when expression has two branches which returns string
> literal,redundant white space will append to the short string literal after
> the ReduceExpressionsRule. For example:
> {code:java}
> case when id>0 then 'a' else 'abc' end{code}
> will actually be convert to
> {code:java}
> case when id>0 then 'a ' else 'abc' end{code}
>
> The reason is that the type of 'a' is CHAR(1),but CHAR(3) for 'abc',so the
> return type of the case-when is CHAR(3). The RexBuilder#ensureType() method
> append a cast convertion for 'a' to cast it to CHAR(3) type.The
> ReduceExpressionsRule execute the cast convertion which fill two whilte space
> to 'a'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2311) case when returns redundant white space
[
https://issues.apache.org/jira/browse/CALCITE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2311:
Description:
If the case-when expression has two branches which returns string
literal,redundant white space will append to the short string literal after
the ReduceExpressionsRule. For example:
{code:java}
case when id>0 then 'a' else 'abc' end{code}
will actually be convert to
{code:java}
case when id>0 then 'a ' else 'abc' end{code}
The reason is that the type of 'a' is CHAR(1),but CHAR(3) for 'abc',so the
return type of the case-when is CHAR(3). The RexBuilder#ensureType() method
append a cast convertion for 'a' to cast it to CHAR(3) type.The
ReduceExpressionsRule execute the cast convertion which fill two whilte space
to 'a'.
was:
If case when has two brach which returns string literal,redundant white space
will append to the short brach.For example:
{code:java}
case when id>0 then 'a' else 'abc' end{code}
will actually be convert to
{code:java}
case when id>0 then 'a ' else 'abc' end{code}
> case when returns redundant white space
> ---
>
> Key: CALCITE-2311
> URL: https://issues.apache.org/jira/browse/CALCITE-2311
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.1.0-incubating
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
>
> If the case-when expression has two branches which returns string
> literal,redundant white space will append to the short string literal after
> the ReduceExpressionsRule. For example:
> {code:java}
> case when id>0 then 'a' else 'abc' end{code}
> will actually be convert to
> {code:java}
> case when id>0 then 'a ' else 'abc' end{code}
>
> The reason is that the type of 'a' is CHAR(1),but CHAR(3) for 'abc',so the
> return type of the case-when is CHAR(3). The RexBuilder#ensureType() method
> append a cast convertion for 'a' to cast it to CHAR(3) type.The
> ReduceExpressionsRule execute the cast convertion which fill two whilte space
> to 'a'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2393) RexSimplify optimization error for expression 'x is not null and x <> 5'
pengzhiwei created CALCITE-2393: --- Summary: RexSimplify optimization error for expression 'x is not null and x <> 5' Key: CALCITE-2393 URL: https://issues.apache.org/jira/browse/CALCITE-2393 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.16.0 Reporter: pengzhiwei Assignee: Julian Hyde Fix For: 1.17.0 After the optimization of RexSimplify,the expression 'x is not null and x <> 5' (x is nullable) is optimized to 'x<> 5' (RexSimplify#unknownAsFalse is true). I think it is not a correct result because when x is null, null<> 5 should return true,while 'x is not null and x <> 5' return false. I think the optimization for "is not null" in RexSimplify#simplifyAnd2ForUnknownAsFalse should exclude the case of not-equal operator. I really confused with this optimization, can you give some suggestion,thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524568#comment-16524568
]
pengzhiwei edited comment on CALCITE-2382 at 6/27/18 4:52 AM:
--
Hello Julian,I have test on top of your branch.A exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has add twice in the JoinScope.
I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it work well.
The table function test PR is here:
https://github.com/apache/calcite/pull/743/commits/8c5ea5a6bc0d1274ad59c2405af188c9a5664724
was (Author: pzw2018):
Hello Julian,I have test on top of your branch.A exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has add twice in the JoinScope.
I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it work well.
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-06-27 下午12.39.46.png
>
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2382:
Attachment: 屏幕快照 2018-06-27 下午12.39.46.png
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-06-27 下午12.39.46.png
>
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524568#comment-16524568
]
pengzhiwei commented on CALCITE-2382:
-
Hello Julian,I have test on top of your branch.A exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has add twice in the JoinScope.
I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it work well.
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-06-27 下午12.39.46.png
>
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524568#comment-16524568
]
pengzhiwei edited comment on CALCITE-2382 at 6/27/18 4:55 AM:
--
Hello Julian,I have test on top of your branch.A exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has added twice in the
JoinScope. I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it work well.
The table function test PR is here:
[https://github.com/apache/calcite/pull/743/commits/8c5ea5a6bc0d1274ad59c2405af188c9a5664724]
was (Author: pzw2018):
Hello Julian,I have test on top of your branch.A exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has add twice in the JoinScope.
I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it work well.
The table function test PR is here:
https://github.com/apache/calcite/pull/743/commits/8c5ea5a6bc0d1274ad59c2405af188c9a5664724
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-06-27 下午12.39.46.png
>
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524568#comment-16524568
]
pengzhiwei edited comment on CALCITE-2382 at 6/27/18 5:00 AM:
--
Hello Julian,I have test on top of your branch.An exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has added twice in the
JoinScope. I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it works well.
The table function test PR is here:
[https://github.com/apache/calcite/pull/743/commits/8c5ea5a6bc0d1274ad59c2405af188c9a5664724]
was (Author: pzw2018):
Hello Julian,I have test on top of your branch.A exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has added twice in the
JoinScope. I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it work well.
The table function test PR is here:
[https://github.com/apache/calcite/pull/743/commits/8c5ea5a6bc0d1274ad59c2405af188c9a5664724]
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-06-27 下午12.39.46.png
>
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2382) Column not found when subquery join lateral table function
pengzhiwei created CALCITE-2382:
---
Summary: Column not found when subquery join lateral table function
Key: CALCITE-2382
URL: https://issues.apache.org/jira/browse/CALCITE-2382
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.16.0
Reporter: pengzhiwei
Assignee: Julian Hyde
When use subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' has thrown out.
I find the reason is that SqlValidatorImpl add the Identifier 's.t' namespace
to the children of tableScope,but not the subquey's namespace,just as the code
show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be right for the child
of tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2382:
Description:
When using subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
I find the reason is that SqlValidatorImpl add the Identifier 's.t' namespace
to the children of tableScope,but not the subquey's namespace,just as the code
show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be right for the child
of tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
was:
When using subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' has thrown out.
I find the reason is that SqlValidatorImpl add the Identifier 's.t' namespace
to the children of tableScope,but not the subquey's namespace,just as the code
show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be right for the child
of tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the Identifier 's.t'
> namespace to the children of tableScope,but not the subquey's namespace,just
> as the code show bellow in SqlValidatorImpl#registerFrom:
>
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
>
>
> I think the namespace of JoinScope's left child should be right for the
> child of tableScope which was referenced by the table function,just as the
> code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
[jira] [Updated] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2382:
Description:
When using subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
I find the reason is that SqlValidatorImpl add the namespace of Identifier
's.t' to the children of tableScope,but not the subquey's namespace,just as
the code show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be the children of
tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
was:
When using subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
I find the reason is that SqlValidatorImpl add the Identifier 's.t' namespace
to the children of tableScope,but not the subquey's namespace,just as the code
show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be right for the child
of tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2382:
Description:
When using subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' has thrown out.
I find the reason is that SqlValidatorImpl add the Identifier 's.t' namespace
to the children of tableScope,but not the subquey's namespace,just as the code
show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be right for the child
of tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
was:
When use subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' has thrown out.
I find the reason is that SqlValidatorImpl add the Identifier 's.t' namespace
to the children of tableScope,but not the subquey's namespace,just as the code
show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be right for the child
of tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' has thrown out.
> I find the reason is that SqlValidatorImpl add the Identifier 's.t'
> namespace to the children of tableScope,but not the subquey's namespace,just
> as the code show bellow in SqlValidatorImpl#registerFrom:
>
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
>
>
> I think the namespace of JoinScope's left child should be right for the
> child of tableScope which was referenced by the table function,just as the
> code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
[jira] [Closed] (CALCITE-2393) RexSimplify optimization error for expression 'x is not null and x <> 5'
[ https://issues.apache.org/jira/browse/CALCITE-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei closed CALCITE-2393. --- Resolution: Not A Problem > RexSimplify optimization error for expression 'x is not null and x <> 5' > - > > Key: CALCITE-2393 > URL: https://issues.apache.org/jira/browse/CALCITE-2393 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.16.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > > After the optimization of RexSimplify,the expression 'x is not null and x > <> 5' (x is nullable) is optimized to 'x<> 5' (RexSimplify#unknownAsFalse is > true). I think it is not a correct result because when x is null, null<> 5 > should return true,while 'x is not null and x <> 5' return false. > I think the optimization for "is not null" in > RexSimplify#simplifyAnd2ForUnknownAsFalse should exclude the case of > not-equal operator. > I really confused with this optimization, can you give some > suggestion,thanks! > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2393) RexSimplify optimization error for expression 'x is not null and x <> 5'
[ https://issues.apache.org/jira/browse/CALCITE-2393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530770#comment-16530770 ] pengzhiwei commented on CALCITE-2393: - Thank [~kgyrtkirk] and [~julianhyde] very much! I have learned a lot. > RexSimplify optimization error for expression 'x is not null and x <> 5' > - > > Key: CALCITE-2393 > URL: https://issues.apache.org/jira/browse/CALCITE-2393 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.16.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Major > Fix For: 1.17.0 > > > After the optimization of RexSimplify,the expression 'x is not null and x > <> 5' (x is nullable) is optimized to 'x<> 5' (RexSimplify#unknownAsFalse is > true). I think it is not a correct result because when x is null, null<> 5 > should return true,while 'x is not null and x <> 5' return false. > I think the optimization for "is not null" in > RexSimplify#simplifyAnd2ForUnknownAsFalse should exclude the case of > not-equal operator. > I really confused with this optimization, can you give some > suggestion,thanks! > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
pengzhiwei created CALCITE-2438:
---
Summary: RexCall#isAlwaysTrue return incorrect result
Key: CALCITE-2438
URL: https://issues.apache.org/jira/browse/CALCITE-2438
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0
Reporter: pengzhiwei
Assignee: Julian Hyde
Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
下午7.34.26.png
In the case as followed:
{code:java}
((sal IS NULL) IS NOT NULL) IS FALSE
{code}
The RexCall#isAlwaysTrue return true,however the correct answer is false.
I find the reason is that there is a wrong logic in the isAlwaysTrue,when
getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
!屏幕快照 2018-08-02 下午7.34.26.png!
Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2438:
Description:
In the expression as followed:
{code:java}
((sal IS NULL) IS NOT NULL) IS FALSE
{code}
The RexCall#isAlwaysTrue return true,however the correct answer is false.
I find the reason is that there is a wrong logic in the isAlwaysTrue,when
getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
!屏幕快照 2018-08-02 下午7.34.26.png!
Can you have a check for me,thanks!
was:
In the case as followed:
{code:java}
((sal IS NULL) IS NOT NULL) IS FALSE
{code}
The RexCall#isAlwaysTrue return true,however the correct answer is false.
I find the reason is that there is a wrong logic in the isAlwaysTrue,when
getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
!屏幕快照 2018-08-02 下午7.34.26.png!
Can you have a check for me,thanks!
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2424) AggregateProjectPullUpConstantsRule throws AssertionError when sql contains "where 'a' is null"
[
https://issues.apache.org/jira/browse/CALCITE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2424:
Affects Version/s: (was: 1.16.0)
1.17.0
> AggregateProjectPullUpConstantsRule throws AssertionError when sql contains
> "where 'a' is null"
> -
>
> Key: CALCITE-2424
> URL: https://issues.apache.org/jira/browse/CALCITE-2424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-07-23 下午4.09.55.png, 屏幕快照 2018-07-23
> 下午4.11.36.png
>
>
> In the sql shown bellow:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> I find the problem arises out of the "where 'a' is null" filter condition
> which is always false.And it result in the relBuilder#aggregate failed to
> generate the new aggregate RelNode in the code as followed in
> AggregateProjectPullUpConstantsRule:
> !屏幕快照 2018-07-23 下午4.11.36.png!
> I think we should do nothing in the ruler in such case when the relBuilder
> failed to generate the new aggreate RelNode.
> I have submit a PR,can you have a check? Thank you.
> Here is the PR:
> https://github.com/apache/calcite/pull/767/commits/70def02bce30392a5ea0c4af904016e3a77b9af1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577111#comment-16577111
]
pengzhiwei commented on CALCITE-2448:
-
I make a pr for this issue,anybody can have a check for me,thanks!
https://github.com/apache/calcite/pull/789
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> The reason is that the relBuilder#aggregate failed to generate new aggregate
> node when the filer condition is always false,just return as followed in
> RelBuilder:
> !屏幕快照 2018-08-06 下午9.09.15.png!
> And then the project created later after relBuilder#aggregate is not really
> based on the aggregate node in AggregateProjectPullUpConstantsRule which
> result in the error.
> !屏幕快照 2018-08-06 下午9.13.56.png!
> I fix the problem by add a logic if the relBuilder#aggregate has not
> generated a aggregate node then just return this rule in
> AggregateProjectPullUpConstantsRule ,just like this:
> !屏幕快照 2018-08-06 下午9.19.48.png!
> Can you have check for me,thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2448:
Comment: was deleted
(was: Hi @[~atris] I am sorry that I have another pr has not been
merged([https://github.com/apache/calcite/pull/778),so] I cannot make the pr at
the moment.
I will make a pr after the last one has been accepted.)
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> The reason is that the relBuilder#aggregate failed to generate new aggregate
> node when the filer condition is always false,just return as followed in
> RelBuilder:
> !屏幕快照 2018-08-06 下午9.09.15.png!
> And then the project created later after relBuilder#aggregate is not really
> based on the aggregate node in AggregateProjectPullUpConstantsRule which
> result in the error.
> !屏幕快照 2018-08-06 下午9.13.56.png!
> I fix the problem by add a logic if the relBuilder#aggregate has not
> generated a aggregate node then just return this rule in
> AggregateProjectPullUpConstantsRule ,just like this:
> !屏幕快照 2018-08-06 下午9.19.48.png!
> Can you have check for me,thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569080#comment-16569080
]
pengzhiwei commented on CALCITE-2438:
-
Hi [~julianhyde] ,here is my pr for this problem:
[https://github.com/apache/calcite/pull/778]
Please have a check for me,thank you!
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571077#comment-16571077
]
pengzhiwei edited comment on CALCITE-2438 at 8/7/18 6:55 AM:
-
I think the PR of [~vladimirsitnikov] is a more general solution! And I think
we can add some more operator case to the RexCall#isAlwaysNull,just like this:
{code:java}
@Override public boolean isAlwaysNull() {
switch (getKind()) {
.
case EQUALS:
case GREATER_THAN:
case GREATER_THAN_OR_EQUAL:
case LESS_THAN:
case LESS_THAN_OR_EQUAL:
case NOT_EQUALS:
return operands.get(0).isAlwaysNull() || operands.get(1).isAlwaysNull();
.
{code}
As we know that the expressions followed return unknown:
{code:java}
NULL = 1
NULL = NULL
NULL > 1
NULL >= 1
NULL < 1
NULL <= 1
NULL <> 1{code}
was (Author: pzw2018):
I think the PR of [~vladimirsitnikov] is a more general solution!
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571077#comment-16571077
]
pengzhiwei commented on CALCITE-2438:
-
I think the pr of [~vladimirsitnikov] is a more general solution!
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571077#comment-16571077
]
pengzhiwei edited comment on CALCITE-2438 at 8/7/18 3:16 AM:
-
I think the PR of [~vladimirsitnikov] is a more general solution!
was (Author: pzw2018):
I think the pr of [~vladimirsitnikov] is a more general solution!
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571077#comment-16571077
]
pengzhiwei edited comment on CALCITE-2438 at 8/7/18 6:32 AM:
-
I think the PR of [~vladimirsitnikov] is a more general solution!
was (Author: pzw2018):
I think the PR of [~vladimirsitnikov] is a more general solution,but just
missing the case IS_TRUE in RexCall#isAlwaysFalse just like this:
{code:java}
@Override public boolean isAlwaysFalse() {
switch (getKind()) {
.
case IS_TRUE:
return operands.get(0).isAlwaysFalse();
}{code}
can you add the this case to you PR [~vladimirsitnikov]? thanks!
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571077#comment-16571077
]
pengzhiwei edited comment on CALCITE-2438 at 8/7/18 6:57 AM:
-
Hi [~julianhyde], I think the PR of [~vladimirsitnikov] is a more general
solution! And I also think we can add some more operator case to the
RexCall#isAlwaysNull,just like this:
{code:java}
@Override public boolean isAlwaysNull() {
switch (getKind()) {
.
case EQUALS:
case GREATER_THAN:
case GREATER_THAN_OR_EQUAL:
case LESS_THAN:
case LESS_THAN_OR_EQUAL:
case NOT_EQUALS:
return operands.get(0).isAlwaysNull() || operands.get(1).isAlwaysNull();
.
{code}
As we know that the expressions followed return unknown:
{code:java}
NULL = 1
NULL = NULL
NULL > 1
NULL >= 1
NULL < 1
NULL <= 1
NULL <> 1{code}
was (Author: pzw2018):
I think the PR of [~vladimirsitnikov] is a more general solution! And I also
think we can add some more operator case to the RexCall#isAlwaysNull,just like
this:
{code:java}
@Override public boolean isAlwaysNull() {
switch (getKind()) {
.
case EQUALS:
case GREATER_THAN:
case GREATER_THAN_OR_EQUAL:
case LESS_THAN:
case LESS_THAN_OR_EQUAL:
case NOT_EQUALS:
return operands.get(0).isAlwaysNull() || operands.get(1).isAlwaysNull();
.
{code}
As we know that the expressions followed return unknown:
{code:java}
NULL = 1
NULL = NULL
NULL > 1
NULL >= 1
NULL < 1
NULL <= 1
NULL <> 1{code}
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571077#comment-16571077
]
pengzhiwei edited comment on CALCITE-2438 at 8/7/18 6:29 AM:
-
I think the PR of [~vladimirsitnikov] is a more general solution,but just
missing the case IS_TRUE in RexCall#isAlwaysFalse just like this:
{code:java}
@Override public boolean isAlwaysFalse() {
switch (getKind()) {
.
case IS_TRUE:
return operands.get(0).isAlwaysFalse();
}{code}
can you add the this case to you PR [~vladimirsitnikov]? thanks!
was (Author: pzw2018):
I think the PR of [~vladimirsitnikov] is a more general solution!
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Description: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . I have made a pr for the problem [https://github.com/apache/calcite/pull/794,|https://github.com/apache/calcite/pull/794,anyone] Anybody can have a check for me,Thanks! was: The RexSimplify has optimized the 'not(x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not(x) is not null' . I have made a pr for the problem [https://github.com/apache/calcite/pull/794,|https://github.com/apache/calcite/pull/794,anyone] Anybody can have a check for me,Thanks! > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > I have made a pr for the problem > [https://github.com/apache/calcite/pull/794,|https://github.com/apache/calcite/pull/794,anyone] > Anybody can have a check for me,Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Description: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . I have made a pr for the problem: [https://github.com/apache/calcite/pull/794|https://github.com/apache/calcite/pull/794,anyone] . Anybody can have a check for me,Thanks! was: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . I have made a pr for the problem [https://github.com/apache/calcite/pull/794,|https://github.com/apache/calcite/pull/794,anyone] Anybody can have a check for me,Thanks! > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > I have made a pr for the problem: > [https://github.com/apache/calcite/pull/794|https://github.com/apache/calcite/pull/794,anyone] > . Anybody can have a check for me,Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Description: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . I have made a pr for the problem: [https://github.com/apache/calcite/pull/794|https://github.com/apache/calcite/pull/794,anyone] Anybody can have a check for me,Thanks! was: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . I have made a pr for the problem: [https://github.com/apache/calcite/pull/794|https://github.com/apache/calcite/pull/794,anyone] . Anybody can have a check for me,Thanks! > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > I have made a pr for the problem: > [https://github.com/apache/calcite/pull/794|https://github.com/apache/calcite/pull/794,anyone] > > Anybody can have a check for me,Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
pengzhiwei created CALCITE-2469: --- Summary: RexSimplify should not optimize 'not(x) is null' to 'x is not null Key: CALCITE-2469 URL: https://issues.apache.org/jira/browse/CALCITE-2469 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.17.0 Reporter: pengzhiwei Assignee: Julian Hyde The RexSimplify has optimized the 'not(x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not(x) is not null' . -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Description: The RexSimplify will optimize the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . was: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Description: The RexSimplify has optimized the 'not(x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not(x) is not null' . I have made a pr for the problem [https://github.com/apache/calcite/pull/794,|https://github.com/apache/calcite/pull/794,anyone] Anybody can have a check for me,Thanks! was:The RexSimplify has optimized the 'not(x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not(x) is not null' . > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify has optimized the 'not(x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not(x) is not null' . > I have made a pr for the problem > [https://github.com/apache/calcite/pull/794,|https://github.com/apache/calcite/pull/794,anyone] > Anybody can have a check for me,Thanks! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Description: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . was: The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . I have made a pr for the problem: [https://github.com/apache/calcite/pull/794|https://github.com/apache/calcite/pull/794,anyone] Anybody can have a check for me,Thanks! > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582069#comment-16582069 ] pengzhiwei commented on CALCITE-2469: - I have made a PR for this problem,Anybody can have a check for me ? Thanks! https://github.com/apache/calcite/pull/794 > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify has optimized the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582745#comment-16582745 ] pengzhiwei edited comment on CALCITE-2469 at 8/16/18 4:04 PM: -- I agree with you [~vladimirsitnikov] that 'not（x） is null' should optimize to 'x is null'.I will add a simlifyIsNull() method in RexSimplify later just like thesimplifyIsNotNull(). . was (Author: pzw2018): I agree with you [~vladimirsitnikov] that 'not(x) is null' should optimize to 'x is null'.I will add a simlifyIsNull() method in RexSimplify later just like thesimplifyIsNotNull(). . > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582745#comment-16582745 ] pengzhiwei commented on CALCITE-2469: - I agree with you [~vladimirsitnikov] that 'not(x) is null' should optimize to 'x is null'.I will add a simlifyIsNull() method in RexSimplify later just like thesimplifyIsNotNull(). . > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582745#comment-16582745 ] pengzhiwei edited comment on CALCITE-2469 at 8/16/18 4:06 PM: -- I agree with you [~vladimirsitnikov] that 'not（x） is null' should optimize to 'x is null'.I will add a simlifyIsNull() method in RexSimplify just like thesimplifyIsNotNull() later. . was (Author: pzw2018): I agree with you [~vladimirsitnikov] that 'not（x） is null' should optimize to 'x is null'.I will add a simlifyIsNull() method in RexSimplify later just like thesimplifyIsNotNull(). . > RexSimplify should not optimize 'not(x) is null' to 'x is not null > -- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583330#comment-16583330 ] pengzhiwei edited comment on CALCITE-2469 at 8/17/18 6:45 AM: -- [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null. And the PR is update to [PR 796|https://github.com/apache/calcite/pull/796] was (Author: pzw2018): [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null. And the PR is update to PR 796 > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2469) RexSimplify should not optimize 'not(x) is null' to 'x is not null
[
https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583298#comment-16583298
]
pengzhiwei commented on CALCITE-2469:
-
Hi @[~vladimirsitnikov]
{noformat}
| I'm not convinced why another method is needed.
| AFAIK, all you need to do regarding this bug is to add proper cases to
negateNullSafe{noformat}
Currently,RexSimplify has not simplified IS NULL expression but done it for IS
NOT NULL in simplifyIsNotNull,so 'not（x） is null' has not simplified to 'x is
null'. If we want to do this simplification for IS NULL, a simplifyIsNull
method should be added just like the simplifyIsNotNull do. Maybe I can do this
in another issue,and just fix this bug here.
> RexSimplify should not optimize 'not(x) is null' to 'x is not null
> --
>
> Key: CALCITE-2469
> URL: https://issues.apache.org/jira/browse/CALCITE-2469
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> The RexSimplify will optimize the 'not（x) is null' to 'x is not null'.
> However,this is incorrect.It is same to the case 'not（x） is not null' .
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583330#comment-16583330 ] pengzhiwei commented on CALCITE-2469: - [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Description: The RexSimplify will optimize the '(not x) is null' to 'x is not null'. However,this is incorrect.It is same to the case '(not x) is not null' . was: The RexSimplify will optimize the 'not（x) is null' to 'x is not null'. However,this is incorrect.It is same to the case 'not（x） is not null' . > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Summary: RexSimplify should not optimize '(not x) is null' to 'x is not null (was: RexSimplify should not optimize 'not(x) is null' to 'x is not null) > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the 'not（x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case 'not（x） is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[
https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2469:
Comment: was deleted
(was: Hi @[~vladimirsitnikov]
{noformat}
| I'm not convinced why another method is needed.
| AFAIK, all you need to do regarding this bug is to add proper cases to
negateNullSafe{noformat}
Currently,RexSimplify has not simplified IS NULL expression but done it for IS
NOT NULL in simplifyIsNotNull,so 'not（x） is null' has not simplified to 'x is
null'. If we want to do this simplification for IS NULL, a simplifyIsNull
method should be added just like the simplifyIsNotNull do. Maybe I can do this
in another issue,and just fix this bug here.)
> RexSimplify should not optimize '(not x) is null' to 'x is not null
> ---
>
> Key: CALCITE-2469
> URL: https://issues.apache.org/jira/browse/CALCITE-2469
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> The RexSimplify will optimize the '(not x) is null' to 'x is not null'.
> However,this is incorrect.It is same to the case '(not x) is not null' .
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16582069#comment-16582069 ] pengzhiwei edited comment on CALCITE-2469 at 8/17/18 6:44 AM: -- I have made a PR for this problem,Anybody can have a check for me ? Thanks! https://github.com/apache/calcite/pull/796 was (Author: pzw2018): I have made a PR for this problem,Anybody can have a check for me ? Thanks! https://github.com/apache/calcite/pull/794 > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583330#comment-16583330 ] pengzhiwei edited comment on CALCITE-2469 at 8/17/18 6:44 AM: -- [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null. And the PR is update to PR 796 was (Author: pzw2018): [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583330#comment-16583330 ] pengzhiwei edited comment on CALCITE-2469 at 8/17/18 6:47 AM: -- [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null. And the PR is updated to [PR 796|https://github.com/apache/calcite/pull/796] was (Author: pzw2018): [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null. And the PR is update to [PR 796|https://github.com/apache/calcite/pull/796] > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null'
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] pengzhiwei updated CALCITE-2469: Summary: RexSimplify should not optimize '(not x) is null' to 'x is not null' (was: RexSimplify should not optimize '(not x) is null' to 'x is not null) > RexSimplify should not optimize '(not x) is null' to 'x is not null' > > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583330#comment-16583330 ] pengzhiwei edited comment on CALCITE-2469 at 8/17/18 9:38 AM: -- [~julianhyde] and [~vladimirsitnikov] I have change the description to '(not x) is null'. And the PR is updated to [PR 796|https://github.com/apache/calcite/pull/796] was (Author: pzw2018): [~julianhyde] and [~vladimirsitnikov] I have change the description to (not x) is null. And the PR is updated to [PR 796|https://github.com/apache/calcite/pull/796] > RexSimplify should not optimize '(not x) is null' to 'x is not null > --- > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2448:
Affects Version/s: 1.17.0
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> The reason is that the relBuilder#aggregate failed to generate new aggregate
> node when the filer condition is always false,just return as followed in
> RelBuilder:
> !屏幕快照 2018-08-06 下午9.09.15.png!
> And then the project created later after relBuilder#aggregate is not really
> based on the a aggregate node which result in the error.
> !屏幕快照 2018-08-06 下午9.13.56.png!
> I fix the problem by add a logic if the relBuilder#aggregate has not
> generated a aggregate node then just return this ruler,just like this:
> !屏幕快照 2018-08-06 下午9.19.48.png!!屏幕快照 2018-08-06 下午9.19.48.png!
> Can you have check for me,thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2448:
Description:
In the sql as followed:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
The reason is that the relBuilder#aggregate failed to generate new aggregate
node when the filer condition is always false,just return as followed in
RelBuilder:
!屏幕快照 2018-08-06 下午9.09.15.png!
And then the project created later after relBuilder#aggregate is not really
based on the aggregate node in AggregateProjectPullUpConstantsRule which
result in the error.
!屏幕快照 2018-08-06 下午9.13.56.png!
I fix the problem by add a logic if the relBuilder#aggregate has not generated
a aggregate node then just return this ruler in
AggregateProjectPullUpConstantsRule ,just like this:
!屏幕快照 2018-08-06 下午9.19.48.png!
Can you have check for me,thanks!
was:
In the sql as followed:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
The reason is that the relBuilder#aggregate failed to generate new aggregate
node when the filer condition is always false,just return as followed in
RelBuilder:
!屏幕快照 2018-08-06 下午9.09.15.png!
And then the project created later after relBuilder#aggregate is not really
based on the a aggregate node which result in the error.
!屏幕快照 2018-08-06 下午9.13.56.png!
I fix the problem by add a logic if the relBuilder#aggregate has not generated
a aggregate node then just return this ruler,just like this:
!屏幕快照 2018-08-06 下午9.19.48.png!!屏幕快照 2018-08-06 下午9.19.48.png!
Can you have check for me,thanks!
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
>
[jira] [Created] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
pengzhiwei created CALCITE-2448:
---
Summary: AggregateProjectPullUpConstantsRule throws AssertionError
Key: CALCITE-2448
URL: https://issues.apache.org/jira/browse/CALCITE-2448
Project: Calcite
Issue Type: Bug
Components: core
Reporter: pengzhiwei
Assignee: Julian Hyde
Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png
In the sql as followed:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
The reason is that the relBuilder#aggregate failed to generate new aggregate
node when the filer condition is always false,just return as followed in
RelBuilder:
!屏幕快照 2018-08-06 下午9.09.15.png!
And then the project created later after relBuilder#aggregate is not really
based on the a aggregate node which result in the error.
!屏幕快照 2018-08-06 下午9.13.56.png!
I fix the problem by add a logic if the relBuilder#aggregate has not generated
a aggregate node then just return this ruler,just like this:
!屏幕快照 2018-08-06 下午9.19.48.png!
Can you have check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2448:
Description:
In the sql as followed:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
The reason is that the relBuilder#aggregate failed to generate new aggregate
node when the filer condition is always false,just return as followed in
RelBuilder:
!屏幕快照 2018-08-06 下午9.09.15.png!
And then the project created later after relBuilder#aggregate is not really
based on the aggregate node in AggregateProjectPullUpConstantsRule which
result in the error.
!屏幕快照 2018-08-06 下午9.13.56.png!
I fix the problem by add a logic if the relBuilder#aggregate has not generated
a aggregate node then just return this rule in
AggregateProjectPullUpConstantsRule ,just like this:
!屏幕快照 2018-08-06 下午9.19.48.png!
Can you have check for me,thanks!
was:
In the sql as followed:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
The reason is that the relBuilder#aggregate failed to generate new aggregate
node when the filer condition is always false,just return as followed in
RelBuilder:
!屏幕快照 2018-08-06 下午9.09.15.png!
And then the project created later after relBuilder#aggregate is not really
based on the aggregate node in AggregateProjectPullUpConstantsRule which
result in the error.
!屏幕快照 2018-08-06 下午9.13.56.png!
I fix the problem by add a logic if the relBuilder#aggregate has not generated
a aggregate node then just return this ruler in
AggregateProjectPullUpConstantsRule ,just like this:
!屏幕快照 2018-08-06 下午9.19.48.png!
Can you have check for me,thanks!
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET
[jira] [Closed] (CALCITE-2424) AggregateProjectPullUpConstantsRule throws AssertionError when sql contains "where 'a' is null"
[
https://issues.apache.org/jira/browse/CALCITE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei closed CALCITE-2424.
---
Resolution: Duplicate
> AggregateProjectPullUpConstantsRule throws AssertionError when sql contains
> "where 'a' is null"
> -
>
> Key: CALCITE-2424
> URL: https://issues.apache.org/jira/browse/CALCITE-2424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-07-23 下午4.09.55.png, 屏幕快照 2018-07-23
> 下午4.11.36.png
>
>
> In the sql shown bellow:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> I find the problem arises out of the "where 'a' is null" filter condition
> which is always false.And it result in the relBuilder#aggregate failed to
> generate the new aggregate RelNode in the code as followed in
> AggregateProjectPullUpConstantsRule:
> !屏幕快照 2018-07-23 下午4.11.36.png!
> I think we should do nothing in the ruler in such case when the relBuilder
> failed to generate the new aggreate RelNode.
> I have submit a PR,can you have a check? Thank you.
> Here is the PR:
> https://github.com/apache/calcite/pull/767/commits/70def02bce30392a5ea0c4af904016e3a77b9af1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2448:
Description:
In the sql as followed:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
The reason is that the relBuilder#aggregate failed to generate new aggregate
node when the filer condition is always false,just return as followed in
RelBuilder:
!屏幕快照 2018-08-06 下午9.09.15.png!
And then the project created later after relBuilder#aggregate is not really
based on the a aggregate node which result in the error.
!屏幕快照 2018-08-06 下午9.13.56.png!
I fix the problem by add a logic if the relBuilder#aggregate has not generated
a aggregate node then just return this ruler,just like this:
!屏幕快照 2018-08-06 下午9.19.48.png!!屏幕快照 2018-08-06 下午9.19.48.png!
Can you have check for me,thanks!
was:
In the sql as followed:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
The reason is that the relBuilder#aggregate failed to generate new aggregate
node when the filer condition is always false,just return as followed in
RelBuilder:
!屏幕快照 2018-08-06 下午9.09.15.png!
And then the project created later after relBuilder#aggregate is not really
based on the a aggregate node which result in the error.
!屏幕快照 2018-08-06 下午9.13.56.png!
I fix the problem by add a logic if the relBuilder#aggregate has not generated
a aggregate node then just return this ruler,just like this:
!屏幕快照 2018-08-06 下午9.19.48.png!
Can you have check for me,thanks!
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1)
[jira] [Updated] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2448:
Attachment: 屏幕快照 2018-08-06 下午9.19.48.png
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> The reason is that the relBuilder#aggregate failed to generate new aggregate
> node when the filer condition is always false,just return as followed in
> RelBuilder:
> !屏幕快照 2018-08-06 下午9.09.15.png!
> And then the project created later after relBuilder#aggregate is not really
> based on the a aggregate node which result in the error.
> !屏幕快照 2018-08-06 下午9.13.56.png!
> I fix the problem by add a logic if the relBuilder#aggregate has not
> generated a aggregate node then just return this ruler,just like this:
> !屏幕快照 2018-08-06 下午9.19.48.png!
> Can you have check for me,thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2438) RexCall#isAlwaysTrue return incorrect result
[
https://issues.apache.org/jira/browse/CALCITE-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571510#comment-16571510
]
pengzhiwei edited comment on CALCITE-2438 at 8/7/18 12:04 PM:
--
Thank [~vladimirsitnikov] ! I have modified the test case, can you have a check
for me again?
[https://github.com/apache/calcite/pull/778]
was (Author: pzw2018):
Thank [~vladimirsitnikov] ! I have modified the test case, can you have a check
for me again.
https://github.com/apache/calcite/pull/778
> RexCall#isAlwaysTrue return incorrect result
> -
>
> Key: CALCITE-2438
> URL: https://issues.apache.org/jira/browse/CALCITE-2438
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-08-02 下午7.26.20.png, 屏幕快照 2018-08-02
> 下午7.34.26.png
>
>
> In the expression as followed:
> {code:java}
> ((sal IS NULL) IS NOT NULL) IS FALSE
> {code}
> The RexCall#isAlwaysTrue return true,however the correct answer is false.
> I find the reason is that there is a wrong logic in the isAlwaysTrue,when
> getKind() is IS_NOT_FALSE、IS_FALSE and IS_NOT_FALSE :
> !屏幕快照 2018-08-02 下午7.34.26.png!
> Can you have a check for me,thanks!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570282#comment-16570282
]
pengzhiwei commented on CALCITE-2448:
-
Hi @[~atris] I am sorry that I have another pr has not been
merged([https://github.com/apache/calcite/pull/778),so] I cannot make the pr at
the moment.
I will make a pr after the last one has been accepted.
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> The reason is that the relBuilder#aggregate failed to generate new aggregate
> node when the filer condition is always false,just return as followed in
> RelBuilder:
> !屏幕快照 2018-08-06 下午9.09.15.png!
> And then the project created later after relBuilder#aggregate is not really
> based on the aggregate node in AggregateProjectPullUpConstantsRule which
> result in the error.
> !屏幕快照 2018-08-06 下午9.13.56.png!
> I fix the problem by add a logic if the relBuilder#aggregate has not
> generated a aggregate node then just return this rule in
> AggregateProjectPullUpConstantsRule ,just like this:
> !屏幕快照 2018-08-06 下午9.19.48.png!
> Can you have check for me,thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16570298#comment-16570298
]
pengzhiwei commented on CALCITE-2448:
-
Hi @[~Sergey Nuyanzin],In the command line mode,the
AggregateProjectPullUpConstantsRule may have not fired.I have added a test in
RelOptRulesTest,the problem really exists!
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> The reason is that the relBuilder#aggregate failed to generate new aggregate
> node when the filer condition is always false,just return as followed in
> RelBuilder:
> !屏幕快照 2018-08-06 下午9.09.15.png!
> And then the project created later after relBuilder#aggregate is not really
> based on the aggregate node in AggregateProjectPullUpConstantsRule which
> result in the error.
> !屏幕快照 2018-08-06 下午9.13.56.png!
> I fix the problem by add a logic if the relBuilder#aggregate has not
> generated a aggregate node then just return this rule in
> AggregateProjectPullUpConstantsRule ,just like this:
> !屏幕快照 2018-08-06 下午9.19.48.png!
> Can you have check for me,thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2448) AggregateProjectPullUpConstantsRule throws AssertionError
[
https://issues.apache.org/jira/browse/CALCITE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16577111#comment-16577111
]
pengzhiwei edited comment on CALCITE-2448 at 8/13/18 3:08 AM:
--
Hi @[~atris] I have made a pr for this issue,can have a check for me,thanks!
[https://github.com/apache/calcite/pull/789]
was (Author: pzw2018):
I make a pr for this issue,anybody can have a check for me,thanks!
https://github.com/apache/calcite/pull/789
> AggregateProjectPullUpConstantsRule throws AssertionError
> -
>
> Key: CALCITE-2448
> URL: https://issues.apache.org/jira/browse/CALCITE-2448
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-08-06 下午9.09.15.png, 屏幕快照 2018-08-06
> 下午9.13.56.png, 屏幕快照 2018-08-06 下午9.19.48.png, 屏幕快照 2018-08-06 下午9.19.48.png
>
>
> In the sql as followed:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> The reason is that the relBuilder#aggregate failed to generate new aggregate
> node when the filer condition is always false,just return as followed in
> RelBuilder:
> !屏幕快照 2018-08-06 下午9.09.15.png!
> And then the project created later after relBuilder#aggregate is not really
> based on the aggregate node in AggregateProjectPullUpConstantsRule which
> result in the error.
> !屏幕快照 2018-08-06 下午9.13.56.png!
> I fix the problem by add a logic if the relBuilder#aggregate has not
> generated a aggregate node then just return this rule in
> AggregateProjectPullUpConstantsRule ,just like this:
> !屏幕快照 2018-08-06 下午9.19.48.png!
> Can you have check for me,thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null'
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593237#comment-16593237 ] pengzhiwei commented on CALCITE-2469: - Hi @[~vladimirsitnikov] ,do we need to fix this issue or need some other work in 1.18.0? > RexSimplify should not optimize '(not x) is null' to 'x is not null' > > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should not optimize '(not x) is null' to 'x is not null'
[ https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583330#comment-16583330 ] pengzhiwei edited comment on CALCITE-2469 at 8/23/18 7:31 AM: -- [~julianhyde] and [~vladimirsitnikov] I have changed the description to '(not x) is null'. And the PR is updated to [PR 796|https://github.com/apache/calcite/pull/796] was (Author: pzw2018): [~julianhyde] and [~vladimirsitnikov] I have change the description to '(not x) is null'. And the PR is updated to [PR 796|https://github.com/apache/calcite/pull/796] > RexSimplify should not optimize '(not x) is null' to 'x is not null' > > > Key: CALCITE-2469 > URL: https://issues.apache.org/jira/browse/CALCITE-2469 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.17.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Critical > > The RexSimplify will optimize the '(not x) is null' to 'x is not null'. > However,this is incorrect.It is same to the case '(not x) is not null' . > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CALCITE-2424) AggregateProjectPullUpConstantsRule throws AssertionError when sql contains "where 'a' is null"
[
https://issues.apache.org/jira/browse/CALCITE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2424:
Summary: AggregateProjectPullUpConstantsRule throws AssertionError when
sql contains "where 'a' is null" (was: AggregateProjectPullUpConstantsRule
throws AssertionError when sql has "where 'a' is null")
> AggregateProjectPullUpConstantsRule throws AssertionError when sql contains
> "where 'a' is null"
> -
>
> Key: CALCITE-2424
> URL: https://issues.apache.org/jira/browse/CALCITE-2424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
> Attachments: 屏幕快照 2018-07-23 下午4.09.55.png, 屏幕快照 2018-07-23
> 下午4.11.36.png
>
>
> In the sql shown bellow:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> I find the problem arises out of the "where 'a' is null" filter condition
> which is always false.And it result in the relBuilder#aggregate failed to
> generate the new aggregate RelNode in the code as followed in
> AggregateProjectPullUpConstantsRule:
> !屏幕快照 2018-07-23 下午4.11.36.png!
> I think we should do nothing in the ruler in such case when the relBuilder
> failed to generate the new aggreate RelNode.
> I have submit a PR,can you have a check? Thank you.
> Here is the PR:
> https://github.com/apache/calcite/pull/767/commits/70def02bce30392a5ea0c4af904016e3a77b9af1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2424) AggregateProjectPullUpConstantsRule throws AssertionError when sql contains "where 'a' is null"
[
https://issues.apache.org/jira/browse/CALCITE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2424:
Fix Version/s: (was: 1.17.0)
> AggregateProjectPullUpConstantsRule throws AssertionError when sql contains
> "where 'a' is null"
> -
>
> Key: CALCITE-2424
> URL: https://issues.apache.org/jira/browse/CALCITE-2424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Attachments: 屏幕快照 2018-07-23 下午4.09.55.png, 屏幕快照 2018-07-23
> 下午4.11.36.png
>
>
> In the sql shown bellow:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
> org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
> at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
> at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
> at
> org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
> {code}
> I find the problem arises out of the "where 'a' is null" filter condition
> which is always false.And it result in the relBuilder#aggregate failed to
> generate the new aggregate RelNode in the code as followed in
> AggregateProjectPullUpConstantsRule:
> !屏幕快照 2018-07-23 下午4.11.36.png!
> I think we should do nothing in the ruler in such case when the relBuilder
> failed to generate the new aggreate RelNode.
> I have submit a PR,can you have a check? Thank you.
> Here is the PR:
> https://github.com/apache/calcite/pull/767/commits/70def02bce30392a5ea0c4af904016e3a77b9af1
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2424) AggregateProjectPullUpConstantsRule throws AssertionError when sql has "where 'a' is null"
[
https://issues.apache.org/jira/browse/CALCITE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2424:
Description:
In the sql shown bellow:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
I find the problem arises out of the "where 'a' is null" filter condition
which is always false.And it result in the relBuilder#aggregate failed to
generate the new aggregate RelNode in the code as followed in
AggregateProjectPullUpConstantsRule:
!屏幕快照 2018-07-23 下午4.11.36.png!
I think we should do nothing in the ruler in such case when the relBuilder
failed to generate the new aggreate RelNode.
I have submit a PR,can you have a check? Thank you.
Here is the PR:https://github.com/apache/calcite/pull/767
was:
In the sql shown bellow:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
I find the problem arises out of the "where 'a' is null" filter condition
which is always false.And it result in the relBuilder#aggregate failed to
generate the new aggregate RelNode in the code as followed in
AggregateProjectPullUpConstantsRule:
!屏幕快照 2018-07-23 下午4.11.36.png!
I think we should do nothing in the ruler in such case when the relBuilder
failed to generate the new aggreate RelNode.
I have submit a PR,can you have a check? Thank you.
> AggregateProjectPullUpConstantsRule throws AssertionError when sql has
> "where 'a' is null"
>
>
> Key: CALCITE-2424
> URL: https://issues.apache.org/jira/browse/CALCITE-2424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
> Attachments: 屏幕快照 2018-07-23 下午4.09.55.png, 屏幕快照 2018-07-23
> 下午4.11.36.png
>
>
> In the sql shown bellow:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
> set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
> expression is LogicalProject#11
> at
>
[jira] [Created] (CALCITE-2424) AggregateProjectPullUpConstantsRule throws AssertionError when sql has "where 'a' is null"
pengzhiwei created CALCITE-2424:
---
Summary: AggregateProjectPullUpConstantsRule throws AssertionError
when sql has "where 'a' is null"
Key: CALCITE-2424
URL: https://issues.apache.org/jira/browse/CALCITE-2424
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.16.0
Reporter: pengzhiwei
Assignee: Julian Hyde
Fix For: 1.17.0
Attachments: 屏幕快照 2018-07-23 下午4.09.55.png, 屏幕快照 2018-07-23
下午4.11.36.png
In the sql shown bellow:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
I find the problem arises out of the "where 'a' is null" filter condition
which is always false.And it result in the relBuilder#aggregate failed to
generate the new aggregate RelNode in the code as followed in
AggregateProjectPullUpConstantsRule:
!屏幕快照 2018-07-23 下午4.11.36.png!
I think we should do nothing in the ruler in such case when the relBuilder
failed to generate the new aggreate RelNode.
I have submit a PR,can you have a check? Thank you.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2424) AggregateProjectPullUpConstantsRule throws AssertionError when sql has "where 'a' is null"
[
https://issues.apache.org/jira/browse/CALCITE-2424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2424:
Description:
In the sql shown bellow:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
I find the problem arises out of the "where 'a' is null" filter condition
which is always false.And it result in the relBuilder#aggregate failed to
generate the new aggregate RelNode in the code as followed in
AggregateProjectPullUpConstantsRule:
!屏幕快照 2018-07-23 下午4.11.36.png!
I think we should do nothing in the ruler in such case when the relBuilder
failed to generate the new aggreate RelNode.
I have submit a PR,can you have a check? Thank you.
Here is the PR:
https://github.com/apache/calcite/pull/767/commits/70def02bce30392a5ea0c4af904016e3a77b9af1
was:
In the sql shown bellow:
{code:java}
select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
{code}
The AggregateProjectPullUpConstantsRule throws an Error like this:
{code:java}
java.lang.AssertionError: Cannot add expression of different type to set:
set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
"ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET "ISO-8859-1"
COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
set is rel#9:LogicalAggregate(input=HepRelVertex#8,group={0, 1})
expression is LogicalProject#11
at org.apache.calcite.plan.RelOptUtil.verifyTypeEquivalence(RelOptUtil.java:380)
at org.apache.calcite.plan.hep.HepRuleCall.transformTo(HepRuleCall.java:57)
at org.apache.calcite.plan.RelOptRuleCall.transformTo(RelOptRuleCall.java:234)
at
org.apache.calcite.rel.rules.AggregateProjectPullUpConstantsRule.onMatch(AggregateProjectPullUpConstantsRule.java:194)
at
org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:315)
{code}
I find the problem arises out of the "where 'a' is null" filter condition
which is always false.And it result in the relBuilder#aggregate failed to
generate the new aggregate RelNode in the code as followed in
AggregateProjectPullUpConstantsRule:
!屏幕快照 2018-07-23 下午4.11.36.png!
I think we should do nothing in the ruler in such case when the relBuilder
failed to generate the new aggreate RelNode.
I have submit a PR,can you have a check? Thank you.
Here is the PR:https://github.com/apache/calcite/pull/767
> AggregateProjectPullUpConstantsRule throws AssertionError when sql has
> "where 'a' is null"
>
>
> Key: CALCITE-2424
> URL: https://issues.apache.org/jira/browse/CALCITE-2424
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
> Fix For: 1.17.0
>
> Attachments: 屏幕快照 2018-07-23 下午4.09.55.png, 屏幕快照 2018-07-23
> 下午4.11.36.png
>
>
> In the sql shown bellow:
> {code:java}
> select 'a',-emp.deptno from emp where 'a' is null group by 'a',-emp.deptno
> {code}
> The AggregateProjectPullUpConstantsRule throws an Error like this:
> {code:java}
> java.lang.AssertionError: Cannot add expression of different type to set:
> set type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, INTEGER NOT NULL EXPR$1) NOT NULL
> expression type is RecordType(CHAR(1) CHARACTER SET "ISO-8859-1" COLLATE
> "ISO-8859-1$en_US$primary" NOT NULL EXPR$0, CHAR(1) CHARACTER SET
> "ISO-8859-1" COLLATE "ISO-8859-1$en_US$primary" NOT NULL EXPR$1) NOT NULL
>
[jira] [Commented] (CALCITE-2469) RexSimplify should optimize '(NOT x) IS NULL' to 'x IS NULL'
[
https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598134#comment-16598134
]
pengzhiwei commented on CALCITE-2469:
-
Hi [~julianhyde],I find same problem in the "improvement for strong functions".
{code:java}
546 + if (simplified == null) {
547 + operands.add(
548+ rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
549+ } else if (simplified.isAlwaysFalse()) {
550+ return rexBuilder.makeLiteral(false);
551+ } else {
{code}
In line 549,I think we should use "simplified.isAlwaysTrue()" here as any of
the operand is null then this RexNode is null.And the return should be "true".
{code:java}
555 + return RexUtil.composeConjunction(rexBuilder, operands, false);
556 + case AS_IS:
{code}
In line 555,Also should we use RexUtil.composeDisjunction() here? For example,
"(a+b) is null" equals "a is null or b is null",but not "a is null and b is
null".
> RexSimplify should optimize '(NOT x) IS NULL' to 'x IS NULL'
>
>
> Key: CALCITE-2469
> URL: https://issues.apache.org/jira/browse/CALCITE-2469
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> The RexSimplify currently optimizes '(not x) is null' to 'x is not null'.
> However, this is incorrect. It is same to the case '(not x) is not null'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should optimize '(NOT x) IS NULL' to 'x IS NULL'
[
https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598134#comment-16598134
]
pengzhiwei edited comment on CALCITE-2469 at 8/31/18 2:36 AM:
--
Hi [~julianhyde],I find same problem in the "improvement for strong functions".
{code:java}
546 + if (simplified == null) {
547 + operands.add(
548+ rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
549+ } else if (simplified.isAlwaysFalse()) {
550+ return rexBuilder.makeLiteral(false);
551+ } else {
{code}
In line 549,I think we should use "simplified.isAlwaysTrue()" here as any of
the operand is null then this RexNode is null.And the return should be "true"
in line 550.
{code:java}
555 + return RexUtil.composeConjunction(rexBuilder, operands, false);
556 + case AS_IS:
{code}
In line 555,Also should we use RexUtil.composeDisjunction() here? For example,
"(a+b) is null" equals "a is null or b is null",but not "a is null and b is
null".
was (Author: pzw2018):
Hi [~julianhyde],I find same problem in the "improvement for strong functions".
{code:java}
546 + if (simplified == null) {
547 + operands.add(
548+ rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
549+ } else if (simplified.isAlwaysFalse()) {
550+ return rexBuilder.makeLiteral(false);
551+ } else {
{code}
In line 549,I think we should use "simplified.isAlwaysTrue()" here as any of
the operand is null then this RexNode is null.And the return should be "true".
{code:java}
555 + return RexUtil.composeConjunction(rexBuilder, operands, false);
556 + case AS_IS:
{code}
In line 555,Also should we use RexUtil.composeDisjunction() here? For example,
"(a+b) is null" equals "a is null or b is null",but not "a is null and b is
null".
> RexSimplify should optimize '(NOT x) IS NULL' to 'x IS NULL'
>
>
> Key: CALCITE-2469
> URL: https://issues.apache.org/jira/browse/CALCITE-2469
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> The RexSimplify currently optimizes '(not x) is null' to 'x is not null'.
> However, this is incorrect. It is same to the case '(not x) is not null'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2469) RexSimplify should optimize '(NOT x) IS NULL' to 'x IS NULL'
[
https://issues.apache.org/jira/browse/CALCITE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598134#comment-16598134
]
pengzhiwei edited comment on CALCITE-2469 at 8/31/18 11:14 AM:
---
Hi [~julianhyde],I find same problem in the "improvement for strong functions".
{code:java}
546 + if (simplified == null) {
547 + operands.add(
548 + rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
549 + } else if (simplified.isAlwaysFalse()) {
550 + return rexBuilder.makeLiteral(false);
551 + } else {
{code}
In line 549,I think we should use "simplified.isAlwaysTrue()" here as any of
the operand is null then this RexNode is null.And the return should be "true"
in line 550.
{code:java}
555 + return RexUtil.composeConjunction(rexBuilder, operands, false);
556 + case AS_IS:
{code}
In line 555,Also should we use RexUtil.composeDisjunction() here? For example,
"(a+b) is null" equals to "a is null or b is null",but not "a is null and b is
null".
was (Author: pzw2018):
Hi [~julianhyde],I find same problem in the "improvement for strong functions".
{code:java}
546 + if (simplified == null) {
547 + operands.add(
548+ rexBuilder.makeCall(SqlStdOperatorTable.IS_NULL, operand));
549+ } else if (simplified.isAlwaysFalse()) {
550+ return rexBuilder.makeLiteral(false);
551+ } else {
{code}
In line 549,I think we should use "simplified.isAlwaysTrue()" here as any of
the operand is null then this RexNode is null.And the return should be "true"
in line 550.
{code:java}
555 + return RexUtil.composeConjunction(rexBuilder, operands, false);
556 + case AS_IS:
{code}
In line 555,Also should we use RexUtil.composeDisjunction() here? For example,
"(a+b) is null" equals to "a is null or b is null",but not "a is null and b is
null".
> RexSimplify should optimize '(NOT x) IS NULL' to 'x IS NULL'
>
>
> Key: CALCITE-2469
> URL: https://issues.apache.org/jira/browse/CALCITE-2469
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> The RexSimplify currently optimizes '(not x) is null' to 'x is not null'.
> However, this is incorrect. It is same to the case '(not x) is not null'.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2551) ClassCastException in SqlToRelConverter#pushDownNotForIn
[
https://issues.apache.org/jira/browse/CALCITE-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2551:
Description:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
was:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
I have made a PR for this issue,anybody can have a check for me? Thanks!
https://github.com/apache/calcite/pull/826
> ClassCastException in SqlToRelConverter#pushDownNotForIn
>
>
> Key: CALCITE-2551
> URL: https://issues.apache.org/jira/browse/CALCITE-2551
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> In the sql as follow:
> {code:java}
> select empno from emp
> where not case when true then deptno in (10,20) else true end
> {code}
> A ClassCastException was thrown out as follow:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be
> cast to org.apache.calcite.sql.SqlBasicCall
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
> at
> {code}
> The problem is that the SqlToRelConverter#pushDownNotForIn method miss
> consideration
> for SqlCase.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2551) ClassCastException in SqlToRelConverter#pushDownNotForIn
[
https://issues.apache.org/jira/browse/CALCITE-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2551:
Description:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
I have made a PR for this issue,anybody can have a check for me? Thanks!
https://github.com/apache/calcite/pull/826
was:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
> ClassCastException in SqlToRelConverter#pushDownNotForIn
>
>
> Key: CALCITE-2551
> URL: https://issues.apache.org/jira/browse/CALCITE-2551
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> In the sql as follow:
> {code:java}
> select empno from emp
> where not case when true then deptno in (10,20) else true end
> {code}
> A ClassCastException was thrown out as follow:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be
> cast to org.apache.calcite.sql.SqlBasicCall
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
> at
> {code}
> The problem is that the SqlToRelConverter#pushDownNotForIn method miss
> consideration
> for SqlCase.
> I have made a PR for this issue,anybody can have a check for me? Thanks!
> https://github.com/apache/calcite/pull/826
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CALCITE-2551) ClassCastException in SqlToRelConverter#pushDownNotForIn
pengzhiwei created CALCITE-2551:
---
Summary: ClassCastException in SqlToRelConverter#pushDownNotForIn
Key: CALCITE-2551
URL: https://issues.apache.org/jira/browse/CALCITE-2551
Project: Calcite
Issue Type: Bug
Components: core
Affects Versions: 1.17.0
Reporter: pengzhiwei
Assignee: Julian Hyde
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2551) ClassCastException in SqlToRelConverter#pushDownNotForIn
[
https://issues.apache.org/jira/browse/CALCITE-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2551:
Description:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
I have made a PR for this issue,anybody can have a check for me? Thanks!
was:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
> ClassCastException in SqlToRelConverter#pushDownNotForIn
>
>
> Key: CALCITE-2551
> URL: https://issues.apache.org/jira/browse/CALCITE-2551
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> In the sql as follow:
> {code:java}
> select empno from emp
> where not case when true then deptno in (10,20) else true end
> {code}
> A ClassCastException was thrown out as follow:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be
> cast to org.apache.calcite.sql.SqlBasicCall
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
> at
> {code}
> The problem is that the SqlToRelConverter#pushDownNotForIn method miss
> consideration
> for SqlCase.
> I have made a PR for this issue,anybody can have a check for me? Thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2551) ClassCastException in SqlToRelConverter#pushDownNotForIn
[
https://issues.apache.org/jira/browse/CALCITE-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2551:
Description:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The reason for this issue is that the SqlToRelConverter#pushDownNotForIn
method missing consideration
for SqlCase.
I have made a PR for this issue which push not down through SqlCase.Anybody can
have a check for me? Thanks!
was:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The problem is that the SqlToRelConverter#pushDownNotForIn method miss
consideration
for SqlCase.
I have made a PR for this issue,anybody can have a check for me? Thanks!
> ClassCastException in SqlToRelConverter#pushDownNotForIn
>
>
> Key: CALCITE-2551
> URL: https://issues.apache.org/jira/browse/CALCITE-2551
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
>
> In the sql as follow:
> {code:java}
> select empno from emp
> where not case when true then deptno in (10,20) else true end
> {code}
> A ClassCastException was thrown out as follow:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be
> cast to org.apache.calcite.sql.SqlBasicCall
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
> at
> {code}
> The reason for this issue is that the SqlToRelConverter#pushDownNotForIn
> method missing consideration
> for SqlCase.
> I have made a PR for this issue which push not down through SqlCase.Anybody
> can have a check for me? Thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2551) ClassCastException in SqlToRelConverter#pushDownNotForIn
[
https://issues.apache.org/jira/browse/CALCITE-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2551:
Attachment: 屏幕快照 2018-09-12 上午11.12.11.png
> ClassCastException in SqlToRelConverter#pushDownNotForIn
>
>
> Key: CALCITE-2551
> URL: https://issues.apache.org/jira/browse/CALCITE-2551
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-09-12 上午11.12.11.png
>
>
> In the sql as follow:
> {code:java}
> select empno from emp
> where not case when true then deptno in (10,20) else true end
> {code}
> A ClassCastException was thrown out as follow:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be
> cast to org.apache.calcite.sql.SqlBasicCall
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
> at
> {code}
> The reason for this issue is that the SqlToRelConverter#pushDownNotForIn
> method missing consideration
> for SqlCase.
> I have made a PR for this issue which push not down through SqlCase.Anybody
> can have a check for me? Thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2551) ClassCastException in SqlToRelConverter#pushDownNotForIn
[
https://issues.apache.org/jira/browse/CALCITE-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2551:
Description:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The reason for this issue is that the SqlToRelConverter#pushDownNotForIn
method missing consideration
for SqlCase as the code shown below:
!屏幕快照 2018-09-12 上午11.12.11.png!
I have made a PR for this issue which push not down through SqlCase.Anybody can
have a check for me? Thanks!
was:
In the sql as follow:
{code:java}
select empno from emp
where not case when true then deptno in (10,20) else true end
{code}
A ClassCastException was thrown out as follow:
{code:java}
java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be cast
to org.apache.calcite.sql.SqlBasicCall
at
org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
at
org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
at
{code}
The reason for this issue is that the SqlToRelConverter#pushDownNotForIn
method missing consideration
for SqlCase.
I have made a PR for this issue which push not down through SqlCase.Anybody can
have a check for me? Thanks!
> ClassCastException in SqlToRelConverter#pushDownNotForIn
>
>
> Key: CALCITE-2551
> URL: https://issues.apache.org/jira/browse/CALCITE-2551
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-09-12 上午11.12.11.png
>
>
> In the sql as follow:
> {code:java}
> select empno from emp
> where not case when true then deptno in (10,20) else true end
> {code}
> A ClassCastException was thrown out as follow:
> {code:java}
> java.lang.ClassCastException: org.apache.calcite.sql.fun.SqlCase cannot be
> cast to org.apache.calcite.sql.SqlBasicCall
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.pushDownNotForIn(SqlToRelConverter.java:987)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:1070)
> at
> {code}
> The reason for this issue is that the SqlToRelConverter#pushDownNotForIn
> method missing consideration
> for SqlCase as the code shown below:
> !屏幕快照 2018-09-12 上午11.12.11.png!
> I have made a PR for this issue which push not down through SqlCase.Anybody
> can have a check for me? Thanks!
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16524568#comment-16524568
]
pengzhiwei edited comment on CALCITE-2382 at 6/29/18 2:42 AM:
--
Hello [~julianhyde],I have test on top of your branch.An exception has thrown
out as follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has added twice in the
JoinScope. I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it works well.
The table function test PR is here:
[https://github.com/apache/calcite/pull/743/commits/8c5ea5a6bc0d1274ad59c2405af188c9a5664724]
was (Author: pzw2018):
Hello Julian,I have test on top of your branch.An exception has thrown out as
follow:
{code:java}
Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Duplicate
relation name 'T' in FROM clause
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:463)
at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:572)
... 50 more
{code}
I find the reason is that the namespace of s.t has added twice in the
JoinScope. I fix it as the code show bellow In SqlValidatorImpl:
!屏幕快照 2018-06-27 下午12.39.46.png!
Now it works well.
The table function test PR is here:
[https://github.com/apache/calcite/pull/743/commits/8c5ea5a6bc0d1274ad59c2405af188c9a5664724]
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-06-27 下午12.39.46.png
>
>
> # When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2382) Column not found when subquery join lateral table function
[
https://issues.apache.org/jira/browse/CALCITE-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2382:
Description:
# When using subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
I find the reason is that SqlValidatorImpl add the namespace of Identifier
's.t' to the children of tableScope,but not the subquey's namespace,just as
the code show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be the children of
tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
was:
When using subquery join lateral table function as followed:
{code:java}
select * from ( select 5 as f0 from s.t ) a,lateral
table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
{code}
'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
I find the reason is that SqlValidatorImpl add the namespace of Identifier
's.t' to the children of tableScope,but not the subquey's namespace,just as
the code show bellow in SqlValidatorImpl#registerFrom:
{code:java}
case IDENTIFIER:
...
if (tableScope == null) {
tableScope = new TableScope(parentScope, node);
}
tableScope.addChild(newNs, alias, forceNullable);{code}
I think the namespace of JoinScope's left child should be the children of
tableScope which was referenced by the table function,just as the code show
bellow in SqlValidatorImpl#registerFrom:
{code:java}
case COLLECTION_TABLE:
TableScope tableScope = null;
if(parentScope instanceof JoinScope) {
tableScope = new TableScope(new EmptyScope(this),operand);
JoinScope scope = (JoinScope) parentScope;
SqlValidatorNamespace leftNs = scope.getChildren().get(0);
tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
}
{code}
After this modification,the case upon runs well.
Is there any problem for this modification? Any suggestions is welcomed.Thanks
a lot.
> Column not found when subquery join lateral table function
> --
>
> Key: CALCITE-2382
> URL: https://issues.apache.org/jira/browse/CALCITE-2382
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.16.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Critical
> Attachments: 屏幕快照 2018-06-27 下午12.39.46.png
>
>
> # When using subquery join lateral table function as followed:
>
> {code:java}
> select * from ( select 5 as f0 from s.t ) a,lateral
> table(s.GenerateStrings(f0)) as t(n, c) where char_length(c) > 3
> {code}
> 'SqlValidatorException: Column 'F0' not found in any table' was thrown out.
> I find the reason is that SqlValidatorImpl add the namespace of Identifier
> 's.t' to the children of tableScope,but not the subquey's namespace,just as
> the code show bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case IDENTIFIER:
> ...
> if (tableScope == null) {
> tableScope = new TableScope(parentScope, node);
> }
> tableScope.addChild(newNs, alias, forceNullable);{code}
> I think the namespace of JoinScope's left child should be the children of
> tableScope which was referenced by the table function,just as the code show
> bellow in SqlValidatorImpl#registerFrom:
> {code:java}
> case COLLECTION_TABLE:
>
> TableScope tableScope = null;
> if(parentScope instanceof JoinScope) {
> tableScope = new TableScope(new EmptyScope(this),operand);
> JoinScope scope = (JoinScope) parentScope;
> SqlValidatorNamespace leftNs = scope.getChildren().get(0);
> tableScope.addChild(leftNs,scope.children.get(0).name,forceNullable);
> }
> {code}
> After this modification,the case upon runs well.
> Is there any problem for this modification? Any suggestions is
> welcomed.Thanks a lot.
>
>
>
>
--
This message was
[jira] [Commented] (CALCITE-2620) Simplify "coalesce(null,x)" to "x"
[ https://issues.apache.org/jira/browse/CALCITE-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648733#comment-16648733 ] pengzhiwei commented on CALCITE-2620: - [~julianhyde],In -CALCITE-2506- this issue has not fixed. I fix it in the [PR882|[http://example.com|https://github.com/apache/calcite/pull/882]] > Simplify "coalesce(null,x)" to "x" > -- > > Key: CALCITE-2620 > URL: https://issues.apache.org/jira/browse/CALCITE-2620 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.18.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Major > > "coalesce(x0,x1,.)" can be simplified if any of "xi" is null literal. > e.g. "coalesce(null,x)" can simplify to "x", "coalesce(x,null,y)" can > simplify to "coalesce(x,y)" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2620) Simplify "coalesce(null,x)" to "x"
[ https://issues.apache.org/jira/browse/CALCITE-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648733#comment-16648733 ] pengzhiwei edited comment on CALCITE-2620 at 10/13/18 4:09 AM: --- [~julianhyde],In -CALCITE-2506- this issue has not fixed. I fix it in the [PR882|https://github.com/apache/calcite/pull/882] was (Author: pzw2018): [~julianhyde],In -CALCITE-2506- this issue has not fixed. I fix it in the [PR882|[http://example.com|https://github.com/apache/calcite/pull/882]] > Simplify "coalesce(null,x)" to "x" > -- > > Key: CALCITE-2620 > URL: https://issues.apache.org/jira/browse/CALCITE-2620 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.18.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Major > > "coalesce(x0,x1,.)" can be simplified if any of "xi" is null literal. > e.g. "coalesce(null,x)" can simplify to "x", "coalesce(x,null,y)" can > simplify to "coalesce(x,y)" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2620) Simplify "coalesce(null,x)" to "x"
[ https://issues.apache.org/jira/browse/CALCITE-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648733#comment-16648733 ] pengzhiwei edited comment on CALCITE-2620 at 10/13/18 4:10 AM: --- [~julianhyde],In -CALCITE-2506- this issue has not fixed. I fix it in the [PR882|https://github.com/apache/calcite/pull/882] ,Please take a look. was (Author: pzw2018): [~julianhyde],In -CALCITE-2506- this issue has not fixed. I fix it in the [PR882|https://github.com/apache/calcite/pull/882] > Simplify "coalesce(null,x)" to "x" > -- > > Key: CALCITE-2620 > URL: https://issues.apache.org/jira/browse/CALCITE-2620 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.18.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Major > > "coalesce(x0,x1,.)" can be simplified if any of "xi" is null literal. > e.g. "coalesce(null,x)" can simplify to "x", "coalesce(x,null,y)" can > simplify to "coalesce(x,y)" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2620) Simplify "coalesce(null,x)" to "x"
[ https://issues.apache.org/jira/browse/CALCITE-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16648733#comment-16648733 ] pengzhiwei edited comment on CALCITE-2620 at 10/13/18 4:09 AM: --- [~julianhyde],In -CALCITE-2506- this issue has not fixed. I fix it in the [PR882|https://github.com/apache/calcite/pull/882] was (Author: pzw2018): [~julianhyde],In -CALCITE-2506- this issue has not fixed. I fix it in the [PR882|https://github.com/apache/calcite/pull/882] > Simplify "coalesce(null,x)" to "x" > -- > > Key: CALCITE-2620 > URL: https://issues.apache.org/jira/browse/CALCITE-2620 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.18.0 >Reporter: pengzhiwei >Assignee: Julian Hyde >Priority: Major > > "coalesce(x0,x1,.)" can be simplified if any of "xi" is null literal. > e.g. "coalesce(null,x)" can simplify to "x", "coalesce(x,null,y)" can > simplify to "coalesce(x,y)" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656240#comment-16656240
]
pengzhiwei commented on CALCITE-2630:
-
Hi [~julianhyde],We are talking about keeping "In (constant1,constant2,...)" as
it is but not translate it to a very complex "join" logical plan as I have
described in the description.We need not add another Rex Operator just like
"plus","minus" and so on.It just a RexCall with a SqlInOperator.
In the runtime of calcite,we can provide a InExpression to compute the value of
"in". We can put all the constants into a "Set" to reduce the computational
complexity .
I think it is much clear and good performance than translate "IN" to a complex
"Join".
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656410#comment-16656410
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 7:57 AM:
---
_By adjusting the subQuertThreshold you can avoid the translation to a join
and have always the OR expansion which does not seem much more complicated than
the equivalent IN._
[~zabetak] The problem I meet in our engine is that when I adjust the
_subQuertThreshold_ to a large value .e.g. 1000,the execution time by OR
expression is
intolerable.
And I think that keeping SqlInOperator in RexCall should not affect other
existing simplify rules.We can also add some new simplify rule for IN.
For example,we can convert the or expression "x=constant1 or x= constant2..."
to "x in (constant1,constant2...)" to reduce the computational complexity for
O（n) to O(1).
was (Author: pzw2018):
_By adjusting the subQuertThreshold you can avoid the translation to a join
and have always the OR expansion which does not seem much more complicated than
the equivalent IN._
[~zabetak] The problem I meet in our engine is that when I adjust the
_subQuertThreshold_ to a large value .e.g. 1000,the execution time by OR
expression is
intolerable.
And I think the keep SqlInOperator in RexCall should not affect other existing
simplify rules.We can also add some new simplify rule for IN.
For example,we can convert the or expression "x=constant1 or x= constant2..."
to "x in (constant1,constant2...)" to reduce the computational complexity for
O（n) to O(1).
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656440#comment-16656440
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 8:30 AM:
---
_you can have your optimized physical IN operator in your generated code_
[~julianhyde] "In Operator" has been translated to "OR" or "Join" after logical
plan,If people want to build a physical IN operator in there own engine ,they
may need to rebuild IN operator from the "OR" or "join" logical plan.It need
lot of work.
So why we not keep "IN" as it is and leave the space for engine to implement
there own physical IN.
Such are my thoughts for this question associated with my work on our
sql-engine based on calcite.
was (Author: pzw2018):
_you can have your optimized physical IN operator in your generated code_
[~julianhyde] "In Operator" has been translated to "OR" or "Join" after logical
plan,If people want to build a physical IN operator in there own engine ,they
may need to rebuild IN operator from the "OR" or "join" logical plan.It need
lot of work.
So why we not keep "IN" as it is and leave the space for engine to implement
there own physical IN.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656440#comment-16656440
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 8:33 AM:
---
_you can have your optimized physical IN operator in your generated code_
[~julianhyde] "In Operator" has been translated to "OR" or "Join" after logical
plan,If people want to build a physical IN operator in there own engine ,they
may need to rebuild IN operator from the "OR" or "join" logical plan.It need
lots of work.
So why we not keep "IN" as it is and leave the space for engine to implement
there own physical IN.
Such are my thoughts for this question associated with my work on our
sql-engine based on calcite.
was (Author: pzw2018):
_you can have your optimized physical IN operator in your generated code_
[~julianhyde] "In Operator" has been translated to "OR" or "Join" after logical
plan,If people want to build a physical IN operator in there own engine ,they
may need to rebuild IN operator from the "OR" or "join" logical plan.It need
lot of work.
So why we not keep "IN" as it is and leave the space for engine to implement
there own physical IN.
Such are my thoughts for this question associated with my work on our
sql-engine based on calcite.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656410#comment-16656410
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 7:56 AM:
---
_By adjusting the subQuertThreshold you can avoid the translation to a join
and have always the OR expansion which does not seem much more complicated than
the equivalent IN._
[~zabetak] The problem I meet in our engine is that when I adjust the
_subQuertThreshold_ to a large value .e.g. 1000,the execution time by OR
expression is
intolerable.
And I think the keep SqlInOperator in RexCall should not affect other existing
simplify rules.We can also add some new simplify rule for IN.
For example,we can convert the or expression "x=constant1 or x= constant2..."
to "x in (constant1,constant2...)" to reduce the computational complexity for
O（n) to O(1).
was (Author: pzw2018):
_By adjusting the subQuertThreshold you can avoid the translation to a join
and have always the OR expansion which does not seem much more complicated than
the equivalent IN._
[~zabetak] The problem I meet in our engine is that when I adjust the
_subQuertThreshold_ to a large value .e.g. 1000,the execution time by OR
expression is
intolerable.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656240#comment-16656240
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 8:01 AM:
---
Hi [~julianhyde],We are talking about keeping "In (constant1,constant2,...)" as
it is but not translate it to a very complex "join" logical plan as I have
described in the description.We need not add another Rex Operator just like
"plus","minus" and so on.It's just a RexCall with a SqlInOperator.
In the runtime of calcite,we can provide a InExpression to compute the value of
"in". We can put all the constants into a "Set" to reduce the computational
complexity .
I think it is much clear and good performance than translate "IN" to a complex
"Join".
was (Author: pzw2018):
Hi [~julianhyde],We are talking about keeping "In (constant1,constant2,...)" as
it is but not translate it to a very complex "join" logical plan as I have
described in the description.We need not add another Rex Operator just like
"plus","minus" and so on.It just a RexCall with a SqlInOperator.
In the runtime of calcite,we can provide a InExpression to compute the value of
"in". We can put all the constants into a "Set" to reduce the computational
complexity .
I think it is much clear and good performance than translate "IN" to a complex
"Join".
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656440#comment-16656440
]
pengzhiwei commented on CALCITE-2630:
-
_you can have your optimized physical IN operator in your generated code_
[~julianhyde] "In Operator" has been translated to "OR" or "Join" after logical
plan,If people want to build a physical IN operator in there own engine ,they
may need to rebuild IN operator from the "OR" or "join" logical plan.It need
lot of work.
So why we not keep "IN" as it is and leave the space for engine to implement
there own physical IN.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656256#comment-16656256
]
pengzhiwei commented on CALCITE-2630:
-
[~zabetak] You are right that it may break the 3rd party rules. Should we add a
config to enable it and disable by default just like the "inSubQueryThreshold"
does ?
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656410#comment-16656410
]
pengzhiwei commented on CALCITE-2630:
-
_By adjusting the subQuertThreshold you can avoid the translation to a join
and have always the OR expansion which does not seem much more complicated than
the equivalent IN._
[~zabetak] The problem I meet in our engine is that when I adjust the
_subQuertThreshold_ to a large value .e.g. 1000,the execution time by OR
expression is
intolerable.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656256#comment-16656256
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 6:51 AM:
---
[~zabetak] You are right that it may break the 3rd party rules. Maybe we can
add a config to enable it and disable it by default just like the
"inSubQueryThreshold" does.
was (Author: pzw2018):
[~zabetak] You are right that it may break the 3rd party rules. Maybe we can
add a config to enable it and disable by default just like the
"inSubQueryThreshold" does.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656256#comment-16656256
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 6:50 AM:
---
[~zabetak] You are right that it may break the 3rd party rules. Maybe we add a
config to enable it and disable by default just like the "inSubQueryThreshold"
does.
was (Author: pzw2018):
[~zabetak] You are right that it may break the 3rd party rules. Should we add a
config to enable it and disable by default just like the "inSubQueryThreshold"
does ?
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16656256#comment-16656256
]
pengzhiwei edited comment on CALCITE-2630 at 10/19/18 6:50 AM:
---
[~zabetak] You are right that it may break the 3rd party rules. Maybe we can
add a config to enable it and disable by default just like the
"inSubQueryThreshold" does.
was (Author: pzw2018):
[~zabetak] You are right that it may break the 3rd party rules. Maybe we add a
config to enable it and disable by default just like the "inSubQueryThreshold"
does.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei reassigned CALCITE-2630:
---
Assignee: pengzhiwei (was: Julian Hyde)
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: pengzhiwei
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
> I think we can treat "IN" as a function like "plus" and "minus".So there is
> no translation on "IN" and just keep it as it is.This would be much clear in
> the logical plan!
> In the execute stage,We can provide a "InExpression":
> {code:java}
> InExpression(left,condition0,condition1,...) {code}
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O（n）to O(1).
> It would be much clear and have a good performance.
> PS: "In sub-query" is not included in our talk.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2630) Convert SqlInOperator to In-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2630:
Description:
Currently Calcite translate "IN" to "OR" expression when the count of IN's
operands less than "inSubQueryThreshold" or to "Join" when the operands count
greater than "inSubQueryThreshold" to get better performance.
However this translation to "JOIN" is so complex. Especially when the "IN"
expression located in the "select" or "join on condition".
For example:
{code:java}
select case when deptno in (1,2) then 0 else 1 end from emp
{code}
the logical plan generated as follow:
{code:java}
LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13), true,
IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
LogicalJoin(condition=[=($11, $12)], joinType=[left])
LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
DEPTNO0=[$7])
LogicalJoin(condition=[true], joinType=[inner])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
LogicalProject(ROW_VALUE=[$0], $f1=[true])
LogicalValues(tuples=[[{ 1 }, { 2 }]])
LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
LogicalProject(ROW_VALUE=[$0], $f1=[true])
LogicalValues(tuples=[[{ 1 }, { 2 }]])
{code}
The generated logical plan is so complex for such a simple sql！
I think we can treat "IN" as a function like "plus" and "minus".So there is no
translation on "IN" and just keep it as it is.This would be much clear in the
logical plan!
In the execute stage,We can provide a "InExpression":
{code:java}
InExpression(left,condition0,condition1,...){code}
We can put all the constant conditions to a "Set".In that way,the
computational complexity can reduce from O（n）to O(1).
It would be much clear and have a good performance.And we have implemented it
in our streaming-sql system.
was:
Currently Calcite translate "IN" to "OR" expression when the count of IN's
operands less than "inSubQueryThreshold" or to "Join" when the operands count
greater than "inSubQueryThreshold" to get better performance.
However this translation to "JOIN" is so complex,especially when the "IN"
expression located in the "select" or "join on condition".
For example:
{code:java}
select case when deptno in (1,2) then 0 else 1 end from emp
{code}
the logical plan generated as follow:
{code:java}
LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13), true,
IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
LogicalJoin(condition=[=($11, $12)], joinType=[left])
LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
DEPTNO0=[$7])
LogicalJoin(condition=[true], joinType=[inner])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
LogicalProject(ROW_VALUE=[$0], $f1=[true])
LogicalValues(tuples=[[{ 1 }, { 2 }]])
LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
LogicalProject(ROW_VALUE=[$0], $f1=[true])
LogicalValues(tuples=[[{ 1 }, { 2 }]])
{code}
The generated logical plan is so complex for such a simple sql！
I think we can treat "IN" as a function like "plus" and "minus".So there is no
translation on "IN" and just keep it as it is.This would be much clear in the
logical plan!
In the execute stage,We can provide a "InExpression":
{code:java}
InExpression(left,condition0,condition1,...){code}
We can put all the constant conditions to a "Set".In that way,the
computational complexity can reduce from O（n）to O(1).
It would be much clear and have a good performance.And we have implemented it
in our streaming-sql system.
> Convert SqlInOperator to In-Expression
> --
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" or to "Join" when the operands
> count greater than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex. Especially when the "IN"
> expression located in the "select" or "join on condition".
> For example:
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
>
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null,
[jira] [Created] (CALCITE-2630) Convert SqlInOperator to a IN-Function
pengzhiwei created CALCITE-2630:
---
Summary: Convert SqlInOperator to a IN-Function
Key: CALCITE-2630
URL: https://issues.apache.org/jira/browse/CALCITE-2630
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.17.0
Reporter: pengzhiwei
Assignee: Julian Hyde
Currently Calcite translate "IN" to "OR" expression when the count of IN's
operands less than "inSubQueryThreshold" and to "Join" when the count greater
than "inSubQueryThreshold" to get better performance.
However this translation to "JOIN" is so complex,especially when the "IN"
expression located in the "select" or "join on condition".For example:
{code:java}
select case when deptno in (1,2) then 0 else 1 end from emp
{code}
the logical plan generated as follow:
{code:java}
LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13), true,
IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
LogicalJoin(condition=[=($11, $12)], joinType=[left])
LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
DEPTNO0=[$7])
LogicalJoin(condition=[true], joinType=[inner])
LogicalTableScan(table=[[CATALOG, SALES, EMP]])
LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
LogicalProject(ROW_VALUE=[$0], $f1=[true])
LogicalValues(tuples=[[{ 1 }, { 2 }]])
LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
LogicalProject(ROW_VALUE=[$0], $f1=[true])
LogicalValues(tuples=[[{ 1 }, { 2 }]])
{code}
The generated logical plan is so complex for such a simple sql！
I think we can treat "IN" as a function like "plus" and "minus".And there is no
translation spending on "IN" just keep it as it is.This would be much clear in
the logical plan!
In the compute stage,We can provide a "InExpression":
{code:java}
InExpression(left,condition0,condition1,...){code}
We can put all the constant conditions to a "Set".In that way,the
computational complexity can reduce from O(n) to O(1).
It would be much clear and have a good performance.And we have implement it in
our streaming-sql system.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CALCITE-2630) Convert SqlInOperator to a IN-Expression
[
https://issues.apache.org/jira/browse/CALCITE-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
pengzhiwei updated CALCITE-2630:
Summary: Convert SqlInOperator to a IN-Expression (was: Convert
SqlInOperator to a IN-Function)
> Convert SqlInOperator to a IN-Expression
>
>
> Key: CALCITE-2630
> URL: https://issues.apache.org/jira/browse/CALCITE-2630
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.17.0
>Reporter: pengzhiwei
>Assignee: Julian Hyde
>Priority: Major
>
> Currently Calcite translate "IN" to "OR" expression when the count of IN's
> operands less than "inSubQueryThreshold" and to "Join" when the count greater
> than "inSubQueryThreshold" to get better performance.
> However this translation to "JOIN" is so complex,especially when the "IN"
> expression located in the "select" or "join on condition".For example:
>
> {code:java}
> select case when deptno in (1,2) then 0 else 1 end from emp
> {code}
> the logical plan generated as follow:
>
>
> {code:java}
> LogicalProject(EXPR$0=[CASE(CAST(CASE(=($9, 0), false, IS NOT NULL($13),
> true, IS NULL($11), null, <($10, $9), null, false)):BOOLEAN NOT NULL, 0, 1)])
> LogicalJoin(condition=[=($11, $12)], joinType=[left])
> LogicalProject(EMPNO=[$0], ENAME=[$1], JOB=[$2], MGR=[$3], HIREDATE=[$4],
> SAL=[$5], COMM=[$6], DEPTNO=[$7], SLACKER=[$8], $f0=[$9], $f1=[$10],
> DEPTNO0=[$7])
> LogicalJoin(condition=[true], joinType=[inner])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> LogicalAggregate(group=[{}], agg#0=[COUNT()], agg#1=[COUNT($0)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> LogicalAggregate(group=[{0}], agg#0=[MIN($1)])
> LogicalProject(ROW_VALUE=[$0], $f1=[true])
> LogicalValues(tuples=[[{ 1 }, { 2 }]])
> {code}
> The generated logical plan is so complex for such a simple sql！
>
> I think we can treat "IN" as a function like "plus" and "minus".And there is
> no translation spending on "IN" just keep it as it is.This would be much
> clear in the logical plan!
> In the compute stage,We can provide a "InExpression":
>
> {code:java}
> InExpression(left,condition0,condition1,...){code}
>
> We can put all the constant conditions to a "Set".In that way,the
> computational complexity can reduce from O(n) to O(1).
> It would be much clear and have a good performance.And we have implement it
> in our streaming-sql system.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
