[jira] [Commented] (CALCITE-2997) Avoid pushing down join condition in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111710#comment-17111710
]
Haisheng Yuan commented on CALCITE-2997:
I agree with [~jinxing6...@126.com]. Instead of providing an option to disable
push down join condition, shall we consider the option to disable the
optimization, return the original logical representation of sqlnode?
> Avoid pushing down join condition in SqlToRelConverter
> --
>
> Key: CALCITE-2997
> URL: https://issues.apache.org/jira/browse/CALCITE-2997
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Assignee: Julian Hyde
>Priority: Major
>
> In current code, *SqlToRelConverter:createJoin* is calling
> *RelOptUtil.pushDownJoinConditions* for optimization. And we can find below
> conversion from *SqlNode* to *RelNode*:
> {code:java}
> SqlNode:
> select * from A join B on A.x = B.x * 2
> RelNode (Logical-Plan):
> Join (condition:col0=col1)
> |-Project(x as col0)
> | |-Scan(A)
> |-Project(x * 2 as col1)
> |-Scan(B){code}
> As we can see the logical plan(*RelNode*) posted above is not the pure
> reflection of the original SQL String(*SqlNode*). The optimization is mixed
> into the phase on which AST is converted to Logical-Plan. Actually optimizing
> rule of JoinPushExpressionsRule is doing exactly the same kind of thing.
> Shall we just keep the optimization inside Optimized-Logical-Plan ? I mean
> shall we avoid calling *RelOptUtil.pushDownJoinConditions* in
> *SqlToRelConverter:createJoin*
> I raised this issue because that we are doing something based on the
> Logical-Plan. And it makes us really confused that the Logical-Plan doesn't
> corresponds to SqlNode.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-2997) Avoid pushing down join condition in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111699#comment-17111699
]
Jin Xing edited comment on CALCITE-2997 at 5/20/20, 2:36 AM:
-
Thanks [~swtalbot] and [~julianhyde] to bring this up ~
Yes, In some scenarios we need SqlToRelConverter to return a logical plan which
corresponds to original SQL String exactly.
Mixing optimizations into the process of building logical plan sometimes make
the user confused.
I would +1 on Julian's idea – – move the rewrite/optimize code into RelBuilder
and add a config to enable/disable, but several concerns as below:
# Should we disable the rewrite/optimize in SqlToRelConverter by default ?
Calcite have clear phases for the lifecycle of a SQL. SqlToRelConverter can
return a purely reflection of the original SQL string, and let the
optimization/rewrite done in the following optimizing phase;
# In addition to pushDownJoinConditions, there are other rewrites like
pushDownNotForIn, shall we disable these optimizing work by default or even
move out of SqlToRelConverter to the optimizaing phase ?
was (Author: jinxing6...@126.com):
Thanks [~swtalbot] and [~julianhyde] to bring this up ~
Yes, In some scenarios we need SqlToRelConverter to return a logical plan which
corresponds to original SQL String exactly.
Mixing optimizations into the process of building logical plan sometimes make
the user confused.
I would +1 on Julian's idea – – move the rewrite/optimize code into RelBuilder
and add a config to enable/disable, but several concerns as below:
# Should we disable the rewrite/optimize in SqlToRelConverter by default ?
Calcite have clear phases for the lifecycle of a SQL. SqlToRelConverter can
return a purely reflection of the original SQL string, and let the
optimization/rewrite done in the following optimizing phase;
# In addition to pushDownJoinConditions, there are other rewrites like
pushDownNotForIn, shall we disable these optimizing work or even move out of
SqlToRelConverter to the optimizaing phase ?
> Avoid pushing down join condition in SqlToRelConverter
> --
>
> Key: CALCITE-2997
> URL: https://issues.apache.org/jira/browse/CALCITE-2997
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Assignee: Julian Hyde
>Priority: Major
>
> In current code, *SqlToRelConverter:createJoin* is calling
> *RelOptUtil.pushDownJoinConditions* for optimization. And we can find below
> conversion from *SqlNode* to *RelNode*:
> {code:java}
> SqlNode:
> select * from A join B on A.x = B.x * 2
> RelNode (Logical-Plan):
> Join (condition:col0=col1)
> |-Project(x as col0)
> | |-Scan(A)
> |-Project(x * 2 as col1)
> |-Scan(B){code}
> As we can see the logical plan(*RelNode*) posted above is not the pure
> reflection of the original SQL String(*SqlNode*). The optimization is mixed
> into the phase on which AST is converted to Logical-Plan. Actually optimizing
> rule of JoinPushExpressionsRule is doing exactly the same kind of thing.
> Shall we just keep the optimization inside Optimized-Logical-Plan ? I mean
> shall we avoid calling *RelOptUtil.pushDownJoinConditions* in
> *SqlToRelConverter:createJoin*
> I raised this issue because that we are doing something based on the
> Logical-Plan. And it makes us really confused that the Logical-Plan doesn't
> corresponds to SqlNode.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2997) Avoid pushing down join condition in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111699#comment-17111699
]
Jin Xing commented on CALCITE-2997:
---
Thanks [~swtalbot] and [~julianhyde] to bring this up ~
Yes, In some scenarios we need SqlToRelConverter to return a logical plan which
corresponds to original SQL String exactly.
Mixing optimizations into the process of building logical plan sometimes make
the user confused.
I would +1 on Julian's idea – – move the rewrite/optimize code into RelBuilder
and add a config to enable/disable, but several concerns as below:
# Should we disable the rewrite/optimize in SqlToRelConverter by default ?
Calcite have clear phases for the lifecycle of a SQL. SqlToRelConverter can
return a purely reflection of the original SQL string, and let the
optimization/rewrite done in the following optimizing phase;
# In addition to pushDownJoinConditions, there are other rewrites like
pushDownNotForIn, shall we disable these optimizing work or even move out of
SqlToRelConverter to the optimizaing phase ?
> Avoid pushing down join condition in SqlToRelConverter
> --
>
> Key: CALCITE-2997
> URL: https://issues.apache.org/jira/browse/CALCITE-2997
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Assignee: Julian Hyde
>Priority: Major
>
> In current code, *SqlToRelConverter:createJoin* is calling
> *RelOptUtil.pushDownJoinConditions* for optimization. And we can find below
> conversion from *SqlNode* to *RelNode*:
> {code:java}
> SqlNode:
> select * from A join B on A.x = B.x * 2
> RelNode (Logical-Plan):
> Join (condition:col0=col1)
> |-Project(x as col0)
> | |-Scan(A)
> |-Project(x * 2 as col1)
> |-Scan(B){code}
> As we can see the logical plan(*RelNode*) posted above is not the pure
> reflection of the original SQL String(*SqlNode*). The optimization is mixed
> into the phase on which AST is converted to Logical-Plan. Actually optimizing
> rule of JoinPushExpressionsRule is doing exactly the same kind of thing.
> Shall we just keep the optimization inside Optimized-Logical-Plan ? I mean
> shall we avoid calling *RelOptUtil.pushDownJoinConditions* in
> *SqlToRelConverter:createJoin*
> I raised this issue because that we are doing something based on the
> Logical-Plan. And it makes us really confused that the Logical-Plan doesn't
> corresponds to SqlNode.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2997) Avoid pushing down join condition in SqlToRelConverter
[
https://issues.apache.org/jira/browse/CALCITE-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111659#comment-17111659
]
Julian Hyde commented on CALCITE-2997:
--
Please review: https://github.com/julianhyde/calcite/tree/2997-join-push
> Avoid pushing down join condition in SqlToRelConverter
> --
>
> Key: CALCITE-2997
> URL: https://issues.apache.org/jira/browse/CALCITE-2997
> Project: Calcite
> Issue Type: Bug
>Reporter: Jin Xing
>Assignee: Julian Hyde
>Priority: Major
>
> In current code, *SqlToRelConverter:createJoin* is calling
> *RelOptUtil.pushDownJoinConditions* for optimization. And we can find below
> conversion from *SqlNode* to *RelNode*:
> {code:java}
> SqlNode:
> select * from A join B on A.x = B.x * 2
> RelNode (Logical-Plan):
> Join (condition:col0=col1)
> |-Project(x as col0)
> | |-Scan(A)
> |-Project(x * 2 as col1)
> |-Scan(B){code}
> As we can see the logical plan(*RelNode*) posted above is not the pure
> reflection of the original SQL String(*SqlNode*). The optimization is mixed
> into the phase on which AST is converted to Logical-Plan. Actually optimizing
> rule of JoinPushExpressionsRule is doing exactly the same kind of thing.
> Shall we just keep the optimization inside Optimized-Logical-Plan ? I mean
> shall we avoid calling *RelOptUtil.pushDownJoinConditions* in
> *SqlToRelConverter:createJoin*
> I raised this issue because that we are doing something based on the
> Logical-Plan. And it makes us really confused that the Logical-Plan doesn't
> corresponds to SqlNode.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3986) Provide config option to omit assigning an alias that is identical to its identifier.
[ https://issues.apache.org/jira/browse/CALCITE-3986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111444#comment-17111444 ] Drew Schmitt commented on CALCITE-3986: --- I mean that it would be nice to be able to keep aliases if they're assigned by the user, but to avoid rendering them in the resulting SQL if they are auto-generated/redundant aliases. For example, for the following input query: select a from abc After parsing into an AST and unparsing to BigQuerySql results in the following query: SELECT a FROM abc AS abc While technically correct, having the extra "AS abc" alias seems like a redundant/more verbose form. > Provide config option to omit assigning an alias that is identical to its > identifier. > - > > Key: CALCITE-3986 > URL: https://issues.apache.org/jira/browse/CALCITE-3986 > Project: Calcite > Issue Type: Improvement >Reporter: Drew Schmitt >Priority: Minor > > The current alias assignment logic with the SqlValidator config option > identifierExpansion() set to true will eagerly try to choose an alias, even > if the alias name ends up being the same as the identifier itself. For > example, it will assign the alias "foo" for the table "foo". > It's nice to have alias assignment, but making it identical to the identifier > doesn't always provide a whole lot of value and can make queries more verbose > than they need to be. > Suggest we add another SqlValidator config option (defaulted to the current > behavior) to allow a caller to disable alias assignment in the cases that it > would be identical to the identifier. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-4015) Pass through parent collation request on subset or superset of join keys for EnumerableMergeJoin
[
https://issues.apache.org/jira/browse/CALCITE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan updated CALCITE-4015:
---
Description:
Pass through parent collation request on subset or superset of join keys for
EnumerableMergeJoin.
e.g.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.b;
{code}
collation on b is passed to mergejoin, mergejoin should generate an alternative
with collation on b, a.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
foo.b, foo.c;
{code}
collation on a,b,c is passed to mergejoin, mergejoin should generate an
alternative with collation on a,b,c, even the join keys are a,b, but since
foo.c is also the output column, mergejoin can still request its child foo to
deliver collation on a,b,c. The join keys must be the collation request's
prefixes (keys order is not required to be reserved).
was:
Pass through parent collation request on subset or superset of join keys for
EnumerableMergeJoin.
e.g.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.b;
{code}
collation on b is passed to mergejoin, mergejoin should generate an alternative
with collation on b, a.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
foo.b, foo.c;
{code}
collation on a,b,c is passed to mergejoin, mergejoin should generate an
alternative with collation on a,b,c, even the join keys are a,b, but since
foo.c is also the output column, mergejoin can still request its child foo to
deliver collation on a,b,c. The join keys must be the collation request's
prefixes.
> Pass through parent collation request on subset or superset of join keys for
> EnumerableMergeJoin
>
>
> Key: CALCITE-4015
> URL: https://issues.apache.org/jira/browse/CALCITE-4015
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Priority: Major
>
> Pass through parent collation request on subset or superset of join keys for
> EnumerableMergeJoin.
> e.g.
> {code:java}
> select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.b;
> {code}
> collation on b is passed to mergejoin, mergejoin should generate an
> alternative with collation on b, a.
> {code:java}
> select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
> foo.b, foo.c;
> {code}
> collation on a,b,c is passed to mergejoin, mergejoin should generate an
> alternative with collation on a,b,c, even the join keys are a,b, but since
> foo.c is also the output column, mergejoin can still request its child foo to
> deliver collation on a,b,c. The join keys must be the collation request's
> prefixes (keys order is not required to be reserved).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4015) Pass through parent collation request on subset or superset of join keys for EnumerableMergeJoin
[
https://issues.apache.org/jira/browse/CALCITE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Haisheng Yuan updated CALCITE-4015:
---
Description:
Pass through parent collation request on subset or superset of join keys for
EnumerableMergeJoin.
e.g.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.b;
{code}
collation on b is passed to mergejoin, mergejoin should generate an alternative
with collation on b, a.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
foo.b, foo.c;
{code}
collation on a,b,c is passed to mergejoin, mergejoin should generate an
alternative with collation on a,b,c, even the join keys are a,b, but since
foo.c is also the output column, mergejoin can still request its child foo to
deliver collation on a,b,c. The join keys must be the collation request's
prefixes.
was:
Pass through parent collation request on subset or superset of join keys for
EnumerableMergeJoin.
e.g.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by b;
{code}
collation on b is passed to mergejoin, mergejoin should generate an alternative
with collation on b, a.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
foo.b, foo.c;
{code}
collation on a,b,c is passed to mergejoin, mergejoin should generate an
alternative with collation on a,b,c, even the join keys are a,b, but since
foo.c is also the output column, mergejoin can still request its child foo to
deliver collation on a,b,c. The join keys must be the collation request's
prefixes.
> Pass through parent collation request on subset or superset of join keys for
> EnumerableMergeJoin
>
>
> Key: CALCITE-4015
> URL: https://issues.apache.org/jira/browse/CALCITE-4015
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Priority: Major
>
> Pass through parent collation request on subset or superset of join keys for
> EnumerableMergeJoin.
> e.g.
> {code:java}
> select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.b;
> {code}
> collation on b is passed to mergejoin, mergejoin should generate an
> alternative with collation on b, a.
> {code:java}
> select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
> foo.b, foo.c;
> {code}
> collation on a,b,c is passed to mergejoin, mergejoin should generate an
> alternative with collation on a,b,c, even the join keys are a,b, but since
> foo.c is also the output column, mergejoin can still request its child foo to
> deliver collation on a,b,c. The join keys must be the collation request's
> prefixes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-4015) Pass through parent collation request on subset or superset of join keys for EnumerableMergeJoin
[
https://issues.apache.org/jira/browse/CALCITE-4015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17111375#comment-17111375
]
Haisheng Yuan commented on CALCITE-4015:
It is open for pick up.
> Pass through parent collation request on subset or superset of join keys for
> EnumerableMergeJoin
>
>
> Key: CALCITE-4015
> URL: https://issues.apache.org/jira/browse/CALCITE-4015
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Haisheng Yuan
>Priority: Major
>
> Pass through parent collation request on subset or superset of join keys for
> EnumerableMergeJoin.
> e.g.
> {code:java}
> select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by b;
> {code}
> collation on b is passed to mergejoin, mergejoin should generate an
> alternative with collation on b, a.
> {code:java}
> select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
> foo.b, foo.c;
> {code}
> collation on a,b,c is passed to mergejoin, mergejoin should generate an
> alternative with collation on a,b,c, even the join keys are a,b, but since
> foo.c is also the output column, mergejoin can still request its child foo to
> deliver collation on a,b,c. The join keys must be the collation request's
> prefixes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4015) Pass through parent collation request on subset or superset of join keys for EnumerableMergeJoin
Haisheng Yuan created CALCITE-4015:
--
Summary: Pass through parent collation request on subset or
superset of join keys for EnumerableMergeJoin
Key: CALCITE-4015
URL: https://issues.apache.org/jira/browse/CALCITE-4015
Project: Calcite
Issue Type: Improvement
Components: core
Reporter: Haisheng Yuan
Pass through parent collation request on subset or superset of join keys for
EnumerableMergeJoin.
e.g.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by b;
{code}
collation on b is passed to mergejoin, mergejoin should generate an alternative
with collation on b, a.
{code:java}
select * from foo join bar on foo.a=bar.a and foo.b=bar.b order by foo.a,
foo.b, foo.c;
{code}
collation on a,b,c is passed to mergejoin, mergejoin should generate an
alternative with collation on a,b,c, even the join keys are a,b, but since
foo.c is also the output column, mergejoin can still request its child foo to
deliver collation on a,b,c. The join keys must be the collation request's
prefixes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-4014) calcite convert(column using utf8mb4) throws exception
groobyming created CALCITE-4014: --- Summary: calcite convert(column using utf8mb4) throws exception Key: CALCITE-4014 URL: https://issues.apache.org/jira/browse/CALCITE-4014 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.21.0 Reporter: groobyming Sql: select convert(name using utf8mb4) from test b where name = '4' errors: org.apache.calcite.runtime.CalciteContextException: From line 1, column 27 to line 1, column 33: Column 'UTF8MB4' not found in any tableorg.apache.calcite.runtime.CalciteContextException: From line 1, column 27 to line 1, column 33: Column 'UTF8MB4' not found in any table 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.sql.SqlUtil.newContextException(SqlUtil.java:834) at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:819) at org.apache.calcite.sql.validate.SqlValidatorImpl.newValidationError(SqlValidatorImpl.java:4870) at org.apache.calcite.sql.validate.DelegatingScope.fullyQualify(DelegatingScope.java:259) at org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:5762) at org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visit(SqlValidatorImpl.java:5747) at org.apache.calcite.sql.SqlIdentifier.accept(SqlIdentifier.java:317) at org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:134) at org.apache.calcite.sql.util.SqlShuttle$CallCopyingArgHandler.visitChild(SqlShuttle.java:101) at org.apache.calcite.sql.SqlOperator.acceptCall(SqlOperator.java:869) at org.apache.calcite.sql.validate.SqlValidatorImpl$Expander.visitScoped(SqlValidatorImpl.java:5780) at org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:50) at org.apache.calcite.sql.validate.SqlScopedShuttle.visit(SqlScopedShuttle.java:33) at org.apache.calcite.sql.SqlCall.accept(SqlCall.java:139) at org.apache.calcite.sql.validate.SqlValidatorImpl.expand(SqlValidatorImpl.java:5354) at org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:450) at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4107) at org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3395) at org.apache.calcite.sql.validate.SelectNamespace.validateImpl(SelectNamespace.java:60) at org.apache.calcite.sql.validate.AbstractNamespace.validate(AbstractNamespace.java:84) at org.apache.calcite.sql.validate.SqlValidatorImpl.validateNamespace(SqlValidatorImpl.java:1008) at org.apache.calcite.sql.validate.SqlValidatorImpl.validateQuery(SqlValidatorImpl.java:968) at org.apache.calcite.sql.SqlSelect.validate(SqlSelect.java:216) at org.apache.calcite.sql.validate.SqlValidatorImpl.validateScopedExpression(SqlValidatorImpl.java:943) at org.apache.calcite.sql.validate.SqlValidatorImpl.validate(SqlValidatorImpl.java:650) at com.tencent.blueking.calcite.udf.FunctionTestTwo.sqlToRelNode(FunctionTestTwo.java:144) at com.tencent.blueking.calcite.udf.FunctionTestTwo.main(FunctionTestTwo.java:87)Caused by: org.apache.calcite.sql.validate.SqlValidatorException: Column 'UTF8MB4' not found in any table 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) ... 27 moreException in thread "main" java.lang.RuntimeException: org.apache.calcite.runtime.CalciteContextException: From line 1, column 27 to line 1, column 33: Column 'UTF8MB4' not found in any table at com.tencent.blueking.calcite.udf.FunctionTestTwo.sqlToRelNode(FunctionTestTwo.java:173) at com.tencent.blueking.calcite.udf.FunctionTestTwo.main(FunctionTestTwo.java:87)Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1, column 27 to line 1, column 33: Column 'UTF8MB4' not found in any table at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at
[jira] [Commented] (CALCITE-4013) Remove traitset derivation when creating logical operators
[ https://issues.apache.org/jira/browse/CALCITE-4013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110902#comment-17110902 ] Haisheng Yuan commented on CALCITE-4013: Physical operator shouldn't do it either, in fact. We shouldn't do it at all when creating operators, no matter it is logical or physical. > Remove traitset derivation when creating logical operators > -- > > Key: CALCITE-4013 > URL: https://issues.apache.org/jira/browse/CALCITE-4013 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Profiler shows traitset derivation accounts for 65% of the total runtime of > LoigcalProject.create(). Anyway, EnumerableProject will do it again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4013) Remove traitset derivation when creating logical operators
Haisheng Yuan created CALCITE-4013: -- Summary: Remove traitset derivation when creating logical operators Key: CALCITE-4013 URL: https://issues.apache.org/jira/browse/CALCITE-4013 Project: Calcite Issue Type: Improvement Components: core Reporter: Haisheng Yuan Profiler shows traitset derivation accounts for 65% of the total runtime of LoigcalProject.create(). Anyway, EnumerableProject will do it again. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2836) Remove maven-compiler-plugin from calcite-plus module pom.xml
[
https://issues.apache.org/jira/browse/CALCITE-2836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110885#comment-17110885
]
Carlos Saltos commented on CALCITE-2836:
Adding {{false}} to the Maven javadoc
pluging configuration also fix the error as a workaround
> Remove maven-compiler-plugin from calcite-plus module pom.xml
> -
>
> Key: CALCITE-2836
> URL: https://issues.apache.org/jira/browse/CALCITE-2836
> Project: Calcite
> Issue Type: Bug
> Components: build
>Reporter: Kevin Risden
>Assignee: Kevin Risden
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.19.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It looks like JDK 11.0.2+ has an issue where 1.8 being specified causes
> javadoc to fail. This has failed for the last few builds on Travis with the
> following error message in the calcite-plus module:
> {code:java}
> javadoc: error - The code being documented uses modules but the packages
> defined in https://docs.oracle.com/javase/8/docs/api/ are in the unnamed
> module.
> {code}
> There is a related JDK bugs about this:
> * [https://bugs.openjdk.java.net/browse/JDK-8212233]
> There is a listed work around but I tested and if we cleanup the leftover
> maven-compiler-plugin part from calcite-plus module this issue goes away.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-4012) Implement trait propagation for EnumerableHashJoin and EnumerableNestedLoopJoin
[ https://issues.apache.org/jira/browse/CALCITE-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan updated CALCITE-4012: --- Summary: Implement trait propagation for EnumerableHashJoin and EnumerableNestedLoopJoin (was: Implement trait propagation for EnumerableHashJoin and EnumerableNestedLoopJoini) > Implement trait propagation for EnumerableHashJoin and > EnumerableNestedLoopJoin > --- > > Key: CALCITE-4012 > URL: https://issues.apache.org/jira/browse/CALCITE-4012 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Priority: Major > > The traitset can be derived from the outer relation of > hashjoin/nestedloopjoin. > They can also pass down parent trait request to their outer child. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4012) Implement trait propagation for EnumerableHashJoin and EnumerableNestedLoopJoini
[ https://issues.apache.org/jira/browse/CALCITE-4012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110883#comment-17110883 ] Haisheng Yuan commented on CALCITE-4012: It is open for pick up. > Implement trait propagation for EnumerableHashJoin and > EnumerableNestedLoopJoini > > > Key: CALCITE-4012 > URL: https://issues.apache.org/jira/browse/CALCITE-4012 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Priority: Major > > The traitset can be derived from the outer relation of > hashjoin/nestedloopjoin. > They can also pass down parent trait request to their outer child. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4012) Implement trait propagation for EnumerableHashJoin and EnumerableNestedLoopJoini
Haisheng Yuan created CALCITE-4012: -- Summary: Implement trait propagation for EnumerableHashJoin and EnumerableNestedLoopJoini Key: CALCITE-4012 URL: https://issues.apache.org/jira/browse/CALCITE-4012 Project: Calcite Issue Type: Improvement Components: core Reporter: Haisheng Yuan The traitset can be derived from the outer relation of hashjoin/nestedloopjoin. They can also pass down parent trait request to their outer child. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-4011) Implement trait propagation for EnumerableProject and EnumerableFilter
Haisheng Yuan created CALCITE-4011: -- Summary: Implement trait propagation for EnumerableProject and EnumerableFilter Key: CALCITE-4011 URL: https://issues.apache.org/jira/browse/CALCITE-4011 Project: Calcite Issue Type: Improvement Components: core Reporter: Haisheng Yuan So that parent trait can be passed down, and it can derive new traitsets from child. Most importantly, as a demonstration. So that SortProjectTransposeRule and ProjectSortTransposeRule can be disabled when topDownOpt is enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-4011) Implement trait propagation for EnumerableProject and EnumerableFilter
[ https://issues.apache.org/jira/browse/CALCITE-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110882#comment-17110882 ] Haisheng Yuan commented on CALCITE-4011: It is open for pick up. > Implement trait propagation for EnumerableProject and EnumerableFilter > -- > > Key: CALCITE-4011 > URL: https://issues.apache.org/jira/browse/CALCITE-4011 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Haisheng Yuan >Priority: Major > > So that parent trait can be passed down, and it can derive new traitsets from > child. Most importantly, as a demonstration. So that SortProjectTransposeRule > and ProjectSortTransposeRule can be disabled when topDownOpt is enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
