[jira] [Comment Edited] (CALCITE-3630) Improve ReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003948#comment-17003948
]
Chunwei Lei edited comment on CALCITE-3630 at 12/27/19 7:39 AM:
Fixed in
[34af9ec1f6066d78a9d8534d8c2531724ac6b127|https://github.com/apache/calcite/commit/34af9ec1f6066d78a9d8534d8c2531724ac6b127].
Thanks for your review, [~danny0405], [~hyuan], [~zabetak]*.*
was (Author: chunwei lei):
Fixed in
[34af9ec1f6066d78a9d8534d8c2531724ac6b127|https://github.com/apache/calcite/commit/34af9ec1f6066d78a9d8534d8c2531724ac6b127]
Thanks for your review, [~danny0405], [~hyuan], [~zabetak]*.*
> Improve ReduceExpressionsRule
> -
>
> Key: CALCITE-3630
> URL: https://issues.apache.org/jira/browse/CALCITE-3630
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In {{FilterReduceExpressionsRule}}, if the expression is a IS [NOT] NULL on a
> non-nullable column, then we can either remove the filter or replace it with
> an Empty(namely {{reduceNotNullableFilter}}). In such a case, we can set
> importance to 0 to reduce search space.
>
> {code:java}
> // code placeholder
> private void reduceNotNullableFilter(
> RelOptRuleCall call,
> Filter filter,
> RexNode rexNode,
> boolean reverse) {
> // If the expression is a IS [NOT] NULL on a non-nullable
> // column, then we can either remove the filter or replace
> // it with an Empty.
> boolean alwaysTrue;
> switch (rexNode.getKind()) {
> case IS_NULL:
> case IS_UNKNOWN:
> alwaysTrue = false;
> break;
> case IS_NOT_NULL:
> alwaysTrue = true;
> break;
> default:
> return;
> }
> if (reverse) {
> alwaysTrue = !alwaysTrue;
> }
> RexNode operand = ((RexCall) rexNode).getOperands().get(0);
> if (operand instanceof RexInputRef) {
> RexInputRef inputRef = (RexInputRef) operand;
> if (!inputRef.getType().isNullable()) {
> if (alwaysTrue) {
> call.transformTo(filter.getInput());
> } else {
> call.transformTo(createEmptyRelOrEquivalent(call, filter));
> }
> }
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3630) Improve ReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chunwei Lei resolved CALCITE-3630.
--
Resolution: Fixed
Fixed in
[34af9ec1f6066d78a9d8534d8c2531724ac6b127|https://github.com/apache/calcite/commit/34af9ec1f6066d78a9d8534d8c2531724ac6b127]
Thanks for your review, [~danny0405], [~hyuan], [~zabetak]*.*
> Improve ReduceExpressionsRule
> -
>
> Key: CALCITE-3630
> URL: https://issues.apache.org/jira/browse/CALCITE-3630
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> In {{FilterReduceExpressionsRule}}, if the expression is a IS [NOT] NULL on a
> non-nullable column, then we can either remove the filter or replace it with
> an Empty(namely {{reduceNotNullableFilter}}). In such a case, we can set
> importance to 0 to reduce search space.
>
> {code:java}
> // code placeholder
> private void reduceNotNullableFilter(
> RelOptRuleCall call,
> Filter filter,
> RexNode rexNode,
> boolean reverse) {
> // If the expression is a IS [NOT] NULL on a non-nullable
> // column, then we can either remove the filter or replace
> // it with an Empty.
> boolean alwaysTrue;
> switch (rexNode.getKind()) {
> case IS_NULL:
> case IS_UNKNOWN:
> alwaysTrue = false;
> break;
> case IS_NOT_NULL:
> alwaysTrue = true;
> break;
> default:
> return;
> }
> if (reverse) {
> alwaysTrue = !alwaysTrue;
> }
> RexNode operand = ((RexCall) rexNode).getOperands().get(0);
> if (operand instanceof RexInputRef) {
> RexInputRef inputRef = (RexInputRef) operand;
> if (!inputRef.getType().isNullable()) {
> if (alwaysTrue) {
> call.transformTo(filter.getInput());
> } else {
> call.transformTo(createEmptyRelOrEquivalent(call, filter));
> }
> }
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3629) Table-valued function implementor interface
[
https://issues.apache.org/jira/browse/CALCITE-3629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003941#comment-17003941
]
Stamatis Zampetakis commented on CALCITE-3629:
--
Makes sense! But as you said in order to be more confident about the addition
we will need some more implementation cases of table-valued functions.
> Table-valued function implementor interface
> ---
>
> Key: CALCITE-3629
> URL: https://issues.apache.org/jira/browse/CALCITE-3629
> Project: Calcite
> Issue Type: Sub-task
>Reporter: Rui Wang
>Assignee: Rui Wang
>Priority: Major
>
> The current implementation of TUMBLE is the following:
> {code:java}
> if (isTumble()) {
>// create expressions and blockstatement
> } else {
> // other table function scan enumerable implementation.
> }
> {code}
> This style is less extensible. We will add more builtin table-valued function
> implementation and we shouldn't add more if-else with complicated
> implementation.
> A better practice is in RexImpTable, each operator register its implementor,
> and then the code will be becomes:
> {code:java}
> if (implementor defined) {
>return implementor.implement(...)
> } else {
> // default table function scan enumerable implementation for those that does
> not have implementor.
> }
> {code}
> The current implementor[1] or [2] is not enough for table-valued function as
> table-valued function need both inputPhysType and outPhysType, and potential
> other params to implement itself.
> Another condition is we might need more table-valued function implementations
> to abstract a common interface.
> [1]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/CallImplementor.java#L38
> [2]:
> https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/adapter/enumerable/NotNullImplementor.java
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3638) Reduce ambiguous hint strategies
[ https://issues.apache.org/jira/browse/CALCITE-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003925#comment-17003925 ] Shuo Cheng commented on CALCITE-3638: - I also think option 2 is better. The SQL will looks chaos if hints are allowed to put right after `group by`, `order by`... AFAIK, no system has hint style like that. > Reduce ambiguous hint strategies > > > Key: CALCITE-3638 > URL: https://issues.apache.org/jira/browse/CALCITE-3638 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT > /*hints*/. Also, hints are designed to be propagable such that the top SELECT > hints can be propagated to other hintable nodes. > For some hint strategies like resource, there will be ambiguity because we > allow it be applicate to more than one type of node (e.g. resource works for > both project and aggregate). > So we could: > 1. want to set resources for project > 2. want to set resources for aggregate > 3. want to set resources for project and aggregate, but have different > parameters. > There are two alternatives: > 1. don't limit hint syntax to the top select. Allow it be put near, e.g. > aggregation, etc. > 2. have different names for the resource hint. e.g. project_resources, > aggregate_resources, etc. > I personally prefer option 1, as it will reduce ambiguity from the root. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3579) Oracle XMLTRANSFORM Function Support
[ https://issues.apache.org/jira/browse/CALCITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen updated CALCITE-3579: Component/s: core > Oracle XMLTRANSFORM Function Support > > > Key: CALCITE-3579 > URL: https://issues.apache.org/jira/browse/CALCITE-3579 > Project: Calcite > Issue Type: Sub-task > Components: core >Reporter: Ritesh >Assignee: Ritesh >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3579) Oracle XMLTRANSFORM Function Support
[ https://issues.apache.org/jira/browse/CALCITE-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-3579. - Fix Version/s: 1.22.0 Resolution: Fixed Fixed in [e7d3f54|https://github.com/apache/calcite/commit/e7d3f545c34efc4f1e9120ca9227fd557cb6], thanks for your PR, [~ritesh.kapoor] ! > Oracle XMLTRANSFORM Function Support > > > Key: CALCITE-3579 > URL: https://issues.apache.org/jira/browse/CALCITE-3579 > Project: Calcite > Issue Type: Sub-task >Reporter: Ritesh >Assignee: Ritesh >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3607) Support LogicalTableModify in RelShuttle
[ https://issues.apache.org/jira/browse/CALCITE-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-3607. - Fix Version/s: 1.22.0 Assignee: Danny Chen Resolution: Fixed Fixed in [b06fd40|https://github.com/apache/calcite/commit/b06fd4094d35c7f61c8e4cb63ce6fc682398d2c7], thanks for your PR, [~xzh_dz] ! > Support LogicalTableModify in RelShuttle > > > Key: CALCITE-3607 > URL: https://issues.apache.org/jira/browse/CALCITE-3607 > Project: Calcite > Issue Type: Wish > Components: core >Reporter: xzh_dz >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 50m > Remaining Estimate: 0h > > RelShuttle don't support LogicalTableModify,this pr try to support > LogicalTableModify in RelShuttle。 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3591) Add BIT_XOR BIT aggregate function
[ https://issues.apache.org/jira/browse/CALCITE-3591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-3591. - Fix Version/s: (was: 1.21.0) Resolution: Fixed Fixed in [e7fc697|https://github.com/apache/calcite/commit/e7fc6977341d0166f110de4218313648de81b336], thanks for your PR, [~hailong wang] ! > Add BIT_XOR BIT aggregate function > -- > > Key: CALCITE-3591 > URL: https://issues.apache.org/jira/browse/CALCITE-3591 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.21.0 >Reporter: hailong wang >Assignee: hailong wang >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > In https://issues.apache.org/jira/browse/CALCITE-2770 , We have support > bit_and、bit_or aggregate function. I think we sholud also support BIT_XOR -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3618) WindowedAggRelSplitter.isDependent is incorrect
[
https://issues.apache.org/jira/browse/CALCITE-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-3618:
Fix Version/s: 1.22.0
> WindowedAggRelSplitter.isDependent is incorrect
> ---
>
> Key: CALCITE-3618
> URL: https://issues.apache.org/jira/browse/CALCITE-3618
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Li Xian
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Attachments: Screen Shot 2019-12-20 at 3.49.09 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> WindowedAggRelSplitter isDependent is incorrect
> {code:java}
> while (!dfs.isEmpty()) {
> int source = dfs.pop();
> if (visited.contains(source)) {
> continue;
> }
> if (source == ordinal1) {
> return true;
> }
> visited.add(source);
> for (DefaultEdge e : graph.getOutwardEdges(source)) {
> int target = (int) e.target;
> if (rank.get(target) < rank.get(ordinal1)) {
> dfs.push(target);
> }
> }
> }
> {code}
> It only pushes target into dfs queue if target rank is smaller than
> ordinal1's rank, which makes it impossible to find the dependency.
> For SQL like
> {code:sql}
> select
> lag(a2, 1, 0) over (partition by "deptno" order by a1) as lagx
> from
> (
> select
>"deptno",
>"salary" / "commission" as a1,
>sum("commission") over ( partition by "deptno" order by "salary" /
> "commission") / sum("commission") over (partition by "deptno") as a2
> from
>"hr"."emps"
> )
> {code}
> It generates levels of exprs like the attached picture below which is
> incorrect.
> To reproduce the error, you can execute the below SQL in the CsvTest
> {code:sql}
> "SELECT
> LAG(A2, 1, 0) OVER (PARTITION BY "GENDER" ORDER BY A1) AS LAGX
> FROM
> (
> SELECT
>"GENDER",
>"EMPNO" / "DEPTNO" AS A1,
>SUM("DEPTNO") OVER ( PARTITION BY "GENDER" ORDER BY "EMPNO" /
> "DEPTNO") / SUM("DEPTNO") OVER (PARTITION BY "GENDER") AS A2
> FROM
>"EMPS"
> ) {code}
> And Calcite will throw the below error
> {code:sql}
> Error while applying rule ProjectToWindowRule:project, args
> [rel#12:LogicalProject.NONE.[](input=RelSubset#11,LAGX=LAG(/(CASE(>(COUNT($2)
> OVER (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING
> AND CURRENT ROW), 0), $SUM0($2) OVER (PARTITION BY $3 ORDER BY /($0, $2)
> RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW), null:INTEGER),
> CASE(>(COUNT($2) OVER (PARTITION BY $3 RANGE BETWEEN UNBOUNDED PRECEDING AND
> UNBOUNDED FOLLOWING), 0), $SUM0($2) OVER (PARTITION BY $3 RANGE BETWEEN
> UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING), null:INTEGER)), 1, 0) OVER
> (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING AND
> CURRENT ROW))]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:408)
> at org.apache.calcite.test.CsvTest.access$300(CsvTest.java:71)
> at org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1066)
> at org.apache.calcite.test.CsvTest.testSelect(CsvTest.java:192)
> Caused by:
> java.lang.RuntimeException: Error while applying rule
> ProjectToWindowRule:project, args
> [rel#12:LogicalProject.NONE.[](input=RelSubset#11,LAGX=LAG(/(CASE(>(COUNT($2)
> OVER (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING
> AND CURRENT ROW), 0), $SUM0($2) OVER (PARTITION BY $3 ORDER BY /($0, $2)
> RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW), null:INTEGER),
> CASE(>(COUNT($2) OVER (PARTITION BY $3 RANGE BETWEEN UNBOUNDED PRECEDING AND
> UNBOUNDED FOLLOWING), 0), $SUM0($2) OVER (PARTITION BY $3 RANGE BETWEEN
> UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING), null:INTEGER)), 1, 0) OVER
> (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING AND
> CURRENT ROW))]
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:238)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:632)
> at
> org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:287)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:347)
> at
[jira] [Resolved] (CALCITE-3618) WindowedAggRelSplitter.isDependent is incorrect
[
https://issues.apache.org/jira/browse/CALCITE-3618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-3618.
-
Resolution: Fixed
Fixed in
[673ac49|https://github.com/apache/calcite/commit/673ac49285df0d4e26879c63425950d95596d363],
thanks for your PR, [~lxian2] !
> WindowedAggRelSplitter.isDependent is incorrect
> ---
>
> Key: CALCITE-3618
> URL: https://issues.apache.org/jira/browse/CALCITE-3618
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Li Xian
>Priority: Major
> Labels: pull-request-available
> Attachments: Screen Shot 2019-12-20 at 3.49.09 PM.png
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> WindowedAggRelSplitter isDependent is incorrect
> {code:java}
> while (!dfs.isEmpty()) {
> int source = dfs.pop();
> if (visited.contains(source)) {
> continue;
> }
> if (source == ordinal1) {
> return true;
> }
> visited.add(source);
> for (DefaultEdge e : graph.getOutwardEdges(source)) {
> int target = (int) e.target;
> if (rank.get(target) < rank.get(ordinal1)) {
> dfs.push(target);
> }
> }
> }
> {code}
> It only pushes target into dfs queue if target rank is smaller than
> ordinal1's rank, which makes it impossible to find the dependency.
> For SQL like
> {code:sql}
> select
> lag(a2, 1, 0) over (partition by "deptno" order by a1) as lagx
> from
> (
> select
>"deptno",
>"salary" / "commission" as a1,
>sum("commission") over ( partition by "deptno" order by "salary" /
> "commission") / sum("commission") over (partition by "deptno") as a2
> from
>"hr"."emps"
> )
> {code}
> It generates levels of exprs like the attached picture below which is
> incorrect.
> To reproduce the error, you can execute the below SQL in the CsvTest
> {code:sql}
> "SELECT
> LAG(A2, 1, 0) OVER (PARTITION BY "GENDER" ORDER BY A1) AS LAGX
> FROM
> (
> SELECT
>"GENDER",
>"EMPNO" / "DEPTNO" AS A1,
>SUM("DEPTNO") OVER ( PARTITION BY "GENDER" ORDER BY "EMPNO" /
> "DEPTNO") / SUM("DEPTNO") OVER (PARTITION BY "GENDER") AS A2
> FROM
>"EMPS"
> ) {code}
> And Calcite will throw the below error
> {code:sql}
> Error while applying rule ProjectToWindowRule:project, args
> [rel#12:LogicalProject.NONE.[](input=RelSubset#11,LAGX=LAG(/(CASE(>(COUNT($2)
> OVER (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING
> AND CURRENT ROW), 0), $SUM0($2) OVER (PARTITION BY $3 ORDER BY /($0, $2)
> RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW), null:INTEGER),
> CASE(>(COUNT($2) OVER (PARTITION BY $3 RANGE BETWEEN UNBOUNDED PRECEDING AND
> UNBOUNDED FOLLOWING), 0), $SUM0($2) OVER (PARTITION BY $3 RANGE BETWEEN
> UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING), null:INTEGER)), 1, 0) OVER
> (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING AND
> CURRENT ROW))]
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:163)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:227)
> at org.apache.calcite.test.CsvTest.checkSql(CsvTest.java:408)
> at org.apache.calcite.test.CsvTest.access$300(CsvTest.java:71)
> at org.apache.calcite.test.CsvTest$Fluent.ok(CsvTest.java:1066)
> at org.apache.calcite.test.CsvTest.testSelect(CsvTest.java:192)
> Caused by:
> java.lang.RuntimeException: Error while applying rule
> ProjectToWindowRule:project, args
> [rel#12:LogicalProject.NONE.[](input=RelSubset#11,LAGX=LAG(/(CASE(>(COUNT($2)
> OVER (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING
> AND CURRENT ROW), 0), $SUM0($2) OVER (PARTITION BY $3 ORDER BY /($0, $2)
> RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW), null:INTEGER),
> CASE(>(COUNT($2) OVER (PARTITION BY $3 RANGE BETWEEN UNBOUNDED PRECEDING AND
> UNBOUNDED FOLLOWING), 0), $SUM0($2) OVER (PARTITION BY $3 RANGE BETWEEN
> UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING), null:INTEGER)), 1, 0) OVER
> (PARTITION BY $3 ORDER BY /($0, $2) RANGE BETWEEN UNBOUNDED PRECEDING AND
> CURRENT ROW))]
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:238)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:632)
> at
> org.apache.calcite.tools.Programs.lambda$standard$3(Programs.java:287)
> at
>
[jira] [Resolved] (CALCITE-3631) Support SQL hints for Calc
[ https://issues.apache.org/jira/browse/CALCITE-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-3631. - Resolution: Fixed Fixed in [5d6e57d|https://github.com/apache/calcite/commit/5d6e57d6efc5ff44f0705a348812f89fa5b237f0], thanks for your PR [~icshuo] ! > Support SQL hints for Calc > -- > > Key: CALCITE-3631 > URL: https://issues.apache.org/jira/browse/CALCITE-3631 > Project: Calcite > Issue Type: Sub-task > Components: core >Affects Versions: 1.21.0 >Reporter: Shuo Cheng >Assignee: Shuo Cheng >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Calc combines the functionality of Project, and it's created in the later > stages of optimization. > So it's necessary to make Calc hintable now. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3630) Improve ReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003897#comment-17003897
]
Chunwei Lei commented on CALCITE-3630:
--
Of course, it can reduce the search space. And it also keeps the same behavior
with the if branch[1]. I don't figure out why we cannot do the same thing if we
already do it in the if branch.
[1]
[https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L194-L216].
> Improve ReduceExpressionsRule
> -
>
> Key: CALCITE-3630
> URL: https://issues.apache.org/jira/browse/CALCITE-3630
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In {{FilterReduceExpressionsRule}}, if the expression is a IS [NOT] NULL on a
> non-nullable column, then we can either remove the filter or replace it with
> an Empty(namely {{reduceNotNullableFilter}}). In such a case, we can set
> importance to 0 to reduce search space.
>
> {code:java}
> // code placeholder
> private void reduceNotNullableFilter(
> RelOptRuleCall call,
> Filter filter,
> RexNode rexNode,
> boolean reverse) {
> // If the expression is a IS [NOT] NULL on a non-nullable
> // column, then we can either remove the filter or replace
> // it with an Empty.
> boolean alwaysTrue;
> switch (rexNode.getKind()) {
> case IS_NULL:
> case IS_UNKNOWN:
> alwaysTrue = false;
> break;
> case IS_NOT_NULL:
> alwaysTrue = true;
> break;
> default:
> return;
> }
> if (reverse) {
> alwaysTrue = !alwaysTrue;
> }
> RexNode operand = ((RexCall) rexNode).getOperands().get(0);
> if (operand instanceof RexInputRef) {
> RexInputRef inputRef = (RexInputRef) operand;
> if (!inputRef.getType().isNullable()) {
> if (alwaysTrue) {
> call.transformTo(filter.getInput());
> } else {
> call.transformTo(createEmptyRelOrEquivalent(call, filter));
> }
> }
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3630) Improve ReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003897#comment-17003897
]
Chunwei Lei edited comment on CALCITE-3630 at 12/27/19 5:49 AM:
Of course, it can reduce the search space. And it also keeps the same behavior
with the if branch[1]. I don't figure out why we cannot do the same thing if we
already do it in the if branch.
[1]
[https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L194-L216].
was (Author: chunwei lei):
Of course, it can reduce the search space. And it also keeps the same behavior
with the if branch[1]. I don't figure out why we cannot do the same thing if we
already do it in the if branch.
[1]
[https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/rel/rules/ReduceExpressionsRule.java#L194-L216].
> Improve ReduceExpressionsRule
> -
>
> Key: CALCITE-3630
> URL: https://issues.apache.org/jira/browse/CALCITE-3630
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In {{FilterReduceExpressionsRule}}, if the expression is a IS [NOT] NULL on a
> non-nullable column, then we can either remove the filter or replace it with
> an Empty(namely {{reduceNotNullableFilter}}). In such a case, we can set
> importance to 0 to reduce search space.
>
> {code:java}
> // code placeholder
> private void reduceNotNullableFilter(
> RelOptRuleCall call,
> Filter filter,
> RexNode rexNode,
> boolean reverse) {
> // If the expression is a IS [NOT] NULL on a non-nullable
> // column, then we can either remove the filter or replace
> // it with an Empty.
> boolean alwaysTrue;
> switch (rexNode.getKind()) {
> case IS_NULL:
> case IS_UNKNOWN:
> alwaysTrue = false;
> break;
> case IS_NOT_NULL:
> alwaysTrue = true;
> break;
> default:
> return;
> }
> if (reverse) {
> alwaysTrue = !alwaysTrue;
> }
> RexNode operand = ((RexCall) rexNode).getOperands().get(0);
> if (operand instanceof RexInputRef) {
> RexInputRef inputRef = (RexInputRef) operand;
> if (!inputRef.getType().isNullable()) {
> if (alwaysTrue) {
> call.transformTo(filter.getInput());
> } else {
> call.transformTo(createEmptyRelOrEquivalent(call, filter));
> }
> }
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3630) Improve ReduceExpressionsRule
[
https://issues.apache.org/jira/browse/CALCITE-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003883#comment-17003883
]
Danny Chen commented on CALCITE-3630:
-
Let's just not analyze the code, can we give a test or example why this change
is necessary, to reduce the search space ?
> Improve ReduceExpressionsRule
> -
>
> Key: CALCITE-3630
> URL: https://issues.apache.org/jira/browse/CALCITE-3630
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Chunwei Lei
>Assignee: Chunwei Lei
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In {{FilterReduceExpressionsRule}}, if the expression is a IS [NOT] NULL on a
> non-nullable column, then we can either remove the filter or replace it with
> an Empty(namely {{reduceNotNullableFilter}}). In such a case, we can set
> importance to 0 to reduce search space.
>
> {code:java}
> // code placeholder
> private void reduceNotNullableFilter(
> RelOptRuleCall call,
> Filter filter,
> RexNode rexNode,
> boolean reverse) {
> // If the expression is a IS [NOT] NULL on a non-nullable
> // column, then we can either remove the filter or replace
> // it with an Empty.
> boolean alwaysTrue;
> switch (rexNode.getKind()) {
> case IS_NULL:
> case IS_UNKNOWN:
> alwaysTrue = false;
> break;
> case IS_NOT_NULL:
> alwaysTrue = true;
> break;
> default:
> return;
> }
> if (reverse) {
> alwaysTrue = !alwaysTrue;
> }
> RexNode operand = ((RexCall) rexNode).getOperands().get(0);
> if (operand instanceof RexInputRef) {
> RexInputRef inputRef = (RexInputRef) operand;
> if (!inputRef.getType().isNullable()) {
> if (alwaysTrue) {
> call.transformTo(filter.getInput());
> } else {
> call.transformTo(createEmptyRelOrEquivalent(call, filter));
> }
> }
> }
> }
> }
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3636) Support Hint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003824#comment-17003824 ] Danny Chen commented on CALCITE-3636: - Thanks for reporting this [~xzh_dz] ~, can you share your cases where the sort hint is needed ? I'm cautious because we don't want to "create requests". > Support Hint for Sort > -- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Sub-task >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3635) Supports hint option as string or numeric literal
[
https://issues.apache.org/jira/browse/CALCITE-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen updated CALCITE-3635:
Parent: CALCITE-482
Issue Type: Sub-task (was: Improvement)
> Supports hint option as string or numeric literal
> -
>
> Key: CALCITE-3635
> URL: https://issues.apache.org/jira/browse/CALCITE-3635
> Project: Calcite
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.21.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Support hint item syntax as:
> {code:sql}
> select /*+ time_zone(1, 1.23, 'a bc', -1.0) */ * from emp
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3635) Supports hint option as string or numeric literal
[
https://issues.apache.org/jira/browse/CALCITE-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Danny Chen resolved CALCITE-3635.
-
Resolution: Fixed
Fixed in
[a52bede|https://github.com/apache/calcite/commit/a52bedeb410824f6dc36b3d668dc194bb0055350]
!
> Supports hint option as string or numeric literal
> -
>
> Key: CALCITE-3635
> URL: https://issues.apache.org/jira/browse/CALCITE-3635
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Support hint item syntax as:
> {code:sql}
> select /*+ time_zone(1, 1.23, 'a bc', -1.0) */ * from emp
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (CALCITE-3571) RelBuilder#shouldMergeProject throws an exception for JOIN with complex conditions
[
https://issues.apache.org/jira/browse/CALCITE-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Kozlov closed CALCITE-3571.
--
Resolution: Duplicate
> RelBuilder#shouldMergeProject throws an exception for JOIN with complex
> conditions
> --
>
> Key: CALCITE-3571
> URL: https://issues.apache.org/jira/browse/CALCITE-3571
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Kirill Kozlov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Table `tblA` schema:
> ||field_name||field_type||
> |id|VARBINARY|
> |fA1|VARCHAR|
> Table `tblB` schema:
> ||field_name||field_type||
> |id|VARCHAR|
> |fB1|VARCHAR|
> For the following query:
> {code:java}
> WITH query as (select SELECT id, fA1, fA1 AS fA1_2 FROM tblA)
> SELECT fA1, fB1, fA1_2
> FROM query
> JOIN tblB ON (TO_HEX(query.id) = tblB.id){code}
> TO_HEX is used as an example, but it can be any other expression; for
> instance `cast(query.id as Integer)`.
> Out of bound exception is thrown in SqlToRelConverter.
>
> Before joins are created left and right paths are parsed first. For the 1st
> query above they are as follows:
> {code:java}
> Left:
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2)
> LogicalTableScan with RecordType(VARBINARY id, VARCHAR fA1)
> Right:
> LogicalTableScan with RecordType(VARCHAR id, VARCHAR fB1){code}
> As they are processed - they are registered as leaves (added to the Array).
>
> When Join node is being created it knows what the `condition expressions` is:
> {code:java}
> =(TO_HEX($0), $3)
> {code}
> Since TO_HEX is not computed anywhere - it modifies the left input to be as
> follows (via RelOptUtil#pushDownJoinConditions) because
> RelBuilder#shouldMergeProject always return true.
> {code:java}
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR $f3)
> {code}
> where `VARCHAR $f3` is a result of TO_HEX. Note that the list of leaves is
> not updated.
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L2571]
>
> Finally, when identifier "query.fA1_2" is being converted (via
> SqlToRelConverter#convertIdentifier) for the top-most node
> {code:java}
> top-most node:
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR id0, VARCHAR fB1)
> LogicalJoin with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR $f3, VARCHAR id0, VARCHAR fB1)
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR $f3)
> LogicalTableScan with RecordType(VARBINARY id, VARCHAR fA1)
> LogicalTableScan with RecordType(VARCHAR id, VARCHAR fB1){code}
> Blackboard perform a lookup (via SqlToRelConverter#lookupExp), in process of
> which LookupContext is created.
> In a constructor, LookupContext performs flatten, which recursively traverses
> tree of nodes (from above codeblock) and checks the leaves to see if they
> contain such expression. When it does get to the modified left input of a
> join it does not get a match on it and continues further down to a TableScan.
> When it finally flattens the result, TableScan's RecordType knows nothing
> about a duplicated field `fA1_2`, causing an error above.
>
> I think a viable solution would be to modify Join creation to register a
> resulting join inputs as leaves (when they are modified). Alternative
> approach would be to not merge Projects when join needs to modify an input.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3571) RelBuilder#shouldMergeProject throws an exception for JOIN with complex conditions
[
https://issues.apache.org/jira/browse/CALCITE-3571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003804#comment-17003804
]
Kirill Kozlov commented on CALCITE-3571:
It appears that the fix for https://issues.apache.org/jira/browse/CALCITE-3575
also resolves this issue as well.
> RelBuilder#shouldMergeProject throws an exception for JOIN with complex
> conditions
> --
>
> Key: CALCITE-3571
> URL: https://issues.apache.org/jira/browse/CALCITE-3571
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.21.0
>Reporter: Kirill Kozlov
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Table `tblA` schema:
> ||field_name||field_type||
> |id|VARBINARY|
> |fA1|VARCHAR|
> Table `tblB` schema:
> ||field_name||field_type||
> |id|VARCHAR|
> |fB1|VARCHAR|
> For the following query:
> {code:java}
> WITH query as (select SELECT id, fA1, fA1 AS fA1_2 FROM tblA)
> SELECT fA1, fB1, fA1_2
> FROM query
> JOIN tblB ON (TO_HEX(query.id) = tblB.id){code}
> TO_HEX is used as an example, but it can be any other expression; for
> instance `cast(query.id as Integer)`.
> Out of bound exception is thrown in SqlToRelConverter.
>
> Before joins are created left and right paths are parsed first. For the 1st
> query above they are as follows:
> {code:java}
> Left:
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2)
> LogicalTableScan with RecordType(VARBINARY id, VARCHAR fA1)
> Right:
> LogicalTableScan with RecordType(VARCHAR id, VARCHAR fB1){code}
> As they are processed - they are registered as leaves (added to the Array).
>
> When Join node is being created it knows what the `condition expressions` is:
> {code:java}
> =(TO_HEX($0), $3)
> {code}
> Since TO_HEX is not computed anywhere - it modifies the left input to be as
> follows (via RelOptUtil#pushDownJoinConditions) because
> RelBuilder#shouldMergeProject always return true.
> {code:java}
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR $f3)
> {code}
> where `VARCHAR $f3` is a result of TO_HEX. Note that the list of leaves is
> not updated.
> [https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L2571]
>
> Finally, when identifier "query.fA1_2" is being converted (via
> SqlToRelConverter#convertIdentifier) for the top-most node
> {code:java}
> top-most node:
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR id0, VARCHAR fB1)
> LogicalJoin with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR $f3, VARCHAR id0, VARCHAR fB1)
> LogicalProject with RecordType(VARBINARY id, VARCHAR fA1, VARCHAR fA1_2,
> VARCHAR $f3)
> LogicalTableScan with RecordType(VARBINARY id, VARCHAR fA1)
> LogicalTableScan with RecordType(VARCHAR id, VARCHAR fB1){code}
> Blackboard perform a lookup (via SqlToRelConverter#lookupExp), in process of
> which LookupContext is created.
> In a constructor, LookupContext performs flatten, which recursively traverses
> tree of nodes (from above codeblock) and checks the leaves to see if they
> contain such expression. When it does get to the modified left input of a
> join it does not get a match on it and continues further down to a TableScan.
> When it finally flattens the result, TableScan's RecordType knows nothing
> about a duplicated field `fA1_2`, causing an error above.
>
> I think a viable solution would be to modify Join creation to register a
> resulting join inputs as leaves (when they are modified). Alternative
> approach would be to not merge Projects when join needs to modify an input.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3636) Support Hint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003801#comment-17003801 ] Rui Wang commented on CALCITE-3636: --- Ok. I think a quick workaround would be to define "sort_resource" and "project_resource" to differentiate them. So it is not a problem. > Support Hint for Sort > -- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Sub-task >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3636) Support Hint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3636: -- Summary: Support Hint for Sort (was: Implement RelHint for Sort ) > Support Hint for Sort > -- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Sub-task >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (CALCITE-3638) Reduce ambiguous hint strategies
[ https://issues.apache.org/jira/browse/CALCITE-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang closed CALCITE-3638. - Resolution: Not A Problem > Reduce ambiguous hint strategies > > > Key: CALCITE-3638 > URL: https://issues.apache.org/jira/browse/CALCITE-3638 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT > /*hints*/. Also, hints are designed to be propagable such that the top SELECT > hints can be propagated to other hintable nodes. > For some hint strategies like resource, there will be ambiguity because we > allow it be applicate to more than one type of node (e.g. resource works for > both project and aggregate). > So we could: > 1. want to set resources for project > 2. want to set resources for aggregate > 3. want to set resources for project and aggregate, but have different > parameters. > There are two alternatives: > 1. don't limit hint syntax to the top select. Allow it be put near, e.g. > aggregation, etc. > 2. have different names for the resource hint. e.g. project_resources, > aggregate_resources, etc. > I personally prefer option 1, as it will reduce ambiguity from the root. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3638) Reduce ambiguous hint strategies
[ https://issues.apache.org/jira/browse/CALCITE-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003800#comment-17003800 ] Rui Wang commented on CALCITE-3638: --- Actually after a second thought, if Calcite does not want to have a limitation on what hints should be allowed, option 2 is better as it will be left engine to decide what hints they will define, which is a much more extensible approach. > Reduce ambiguous hint strategies > > > Key: CALCITE-3638 > URL: https://issues.apache.org/jira/browse/CALCITE-3638 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT > /*hints*/. Also, hints are designed to be propagable such that the top SELECT > hints can be propagated to other hintable nodes. > For some hint strategies like resource, there will be ambiguity because we > allow it be applicate to more than one type of node (e.g. resource works for > both project and aggregate). > So we could: > 1. want to set resources for project > 2. want to set resources for aggregate > 3. want to set resources for project and aggregate, but have different > parameters. > There are two alternatives: > 1. don't limit hint syntax to the top select. Allow it be put near, e.g. > aggregation, etc. > 2. have different names for the resource hint. e.g. project_resources, > aggregate_resources, etc. > I personally prefer option 1, as it will reduce ambiguity from the root. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3638) Reduce ambiguous hint strategies
[ https://issues.apache.org/jira/browse/CALCITE-3638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3638: -- Description: Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT /*hints*/. Also, hints are designed to be propagable such that the top SELECT hints can be propagated to other hintable nodes. For some hint strategies like resource, there will be ambiguity because we allow it be applicate to more than one type of node (e.g. resource works for both project and aggregate). So we could: 1. want to set resources for project 2. want to set resources for aggregate 3. want to set resources for project and aggregate, but have different parameters. There are two alternatives: 1. don't limit hint syntax to the top select. Allow it be put near, e.g. aggregation, etc. 2. have different names for the resource hint. e.g. project_resources, aggregate_resources, etc. I personally prefer option 1, as it will reduce ambiguity from the root. was: Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT /*hints*/. Also, hints are designed to be propagable such that the top SELECT hints can be propagated to other hintable nodes. For some hint strategies like resource, there will be ambiguity because we allow it be applicate to more than one type of node (e.g. resource works for both project and aggregate). So we could: 1. want to set resources for project 2. want to set resources for aggregate 3. want to set resources for project and aggregate, but have different parameters. There are two alternatives: 1. don't limit hint syntax to the top select. Allow it be put near, e.g. aggregation, etc. 2. have different names for the resource hint. e.g. project_resources, aggregate_resources, etc. > Reduce ambiguous hint strategies > > > Key: CALCITE-3638 > URL: https://issues.apache.org/jira/browse/CALCITE-3638 > Project: Calcite > Issue Type: Sub-task >Reporter: Rui Wang >Assignee: Rui Wang >Priority: Major > > Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT > /*hints*/. Also, hints are designed to be propagable such that the top SELECT > hints can be propagated to other hintable nodes. > For some hint strategies like resource, there will be ambiguity because we > allow it be applicate to more than one type of node (e.g. resource works for > both project and aggregate). > So we could: > 1. want to set resources for project > 2. want to set resources for aggregate > 3. want to set resources for project and aggregate, but have different > parameters. > There are two alternatives: > 1. don't limit hint syntax to the top select. Allow it be put near, e.g. > aggregation, etc. > 2. have different names for the resource hint. e.g. project_resources, > aggregate_resources, etc. > I personally prefer option 1, as it will reduce ambiguity from the root. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3638) Reduce ambiguous hint strategies
Rui Wang created CALCITE-3638: - Summary: Reduce ambiguous hint strategies Key: CALCITE-3638 URL: https://issues.apache.org/jira/browse/CALCITE-3638 Project: Calcite Issue Type: Sub-task Reporter: Rui Wang Assignee: Rui Wang Right now hint syntax prefers to keep hints near the top SELECT, e.g. SELECT /*hints*/. Also, hints are designed to be propagable such that the top SELECT hints can be propagated to other hintable nodes. For some hint strategies like resource, there will be ambiguity because we allow it be applicate to more than one type of node (e.g. resource works for both project and aggregate). So we could: 1. want to set resources for project 2. want to set resources for aggregate 3. want to set resources for project and aggregate, but have different parameters. There are two alternatives: 1. don't limit hint syntax to the top select. Allow it be put near, e.g. aggregation, etc. 2. have different names for the resource hint. e.g. project_resources, aggregate_resources, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3636) Implement RelHint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003770#comment-17003770 ] Rui Wang edited comment on CALCITE-3636 at 12/26/19 9:38 PM: - I converted this Jira to a subtask of CALCITE-482. Per the PR I think you want to propagate resource hint to sort and there is the syntax in the PR: select /*+ resource(mem='1024MB')*/ ename, sal, deptno from emp order by deptno"; Until this moment, as we are adding more and more hintable RelNode, I start to think how to distinguish the following cases: 1. resources only applied to Project 2. resources only applied to Sort 3. resources applied to both Sort and Project. My question is, will the following syntax better for case 2? select ename, sal, deptno from emp order by /*+ resource(mem='1024MB')*/ deptno" ? cc: @danny0405 was (Author: amaliujia): I converted this Jira to a subtask of CALCITE-482. Per the PR I think you want to propagate resource hint to sort and there is the syntax in the PR: select /*+ resource(mem='1024MB')*/ ename, sal, deptno from emp order by deptno"; Until this moment, as we are adding more and more hintable RelNode, I start to think how to distinguish the following cases: 1. resources only applied to Project 2. resources only applied to Sort 3. resources applied to both Sort and Project. My question is, will the following syntax better? select ename, sal, deptno from emp order by /*+ resource(mem='1024MB')*/ deptno" ? cc: @danny0405 > Implement RelHint for Sort > --- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Sub-task >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3636) Implement RelHint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003770#comment-17003770 ] Rui Wang edited comment on CALCITE-3636 at 12/26/19 9:34 PM: - I converted this Jira to a subtask of CALCITE-482. Per the PR I think you want to propagate resource hint to sort and there is the syntax in the PR: select /*+ resource(mem='1024MB')*/ ename, sal, deptno from emp order by deptno"; My question is, will the following syntax better? select ename, sal, deptno from emp order by /*+ resource(mem='1024MB')*/ deptno" ? cc: @danny0405 was (Author: amaliujia): Can you convert this Jira to a subtask of CALCITE-482? Per the PR I think you want to propagate resource hint to sort and there is the syntax in the PR: select /*+ resource(mem='1024MB')*/ ename, sal, deptno from emp order by deptno"; My question is, will the following syntax better? select ename, sal, deptno from emp order by /*+ resource(mem='1024MB')*/ deptno" ? cc: @danny0405 > Implement RelHint for Sort > --- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Sub-task >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3636) Implement RelHint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rui Wang updated CALCITE-3636: -- Parent: CALCITE-482 Issue Type: Sub-task (was: Wish) > Implement RelHint for Sort > --- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Sub-task >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3636) Implement RelHint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003770#comment-17003770 ] Rui Wang commented on CALCITE-3636: --- Can you convert this Jira to a subtask of CALCITE-482? Per the PR I think you want to propagate resource hint to sort and there is the syntax in the PR: select /*+ resource(mem='1024MB')*/ ename, sal, deptno from emp order by deptno"; My question is, will the following syntax better? select ename, sal, deptno from emp order by /*+ resource(mem='1024MB')*/ deptno" ? cc: @danny0405 > Implement RelHint for Sort > --- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3637) Update linq4j tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3637: Labels: pull-request-available (was: ) > Update linq4j tests upgrade from junit4 to junit5 > - > > Key: CALCITE-3637 > URL: https://issues.apache.org/jira/browse/CALCITE-3637 > Project: Calcite > Issue Type: Improvement >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > > Update `linq4j` tests upgrade from junit4 to junit5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-3637) Update linq4j tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Forward Xu reassigned CALCITE-3637: --- Assignee: Forward Xu > Update linq4j tests upgrade from junit4 to junit5 > - > > Key: CALCITE-3637 > URL: https://issues.apache.org/jira/browse/CALCITE-3637 > Project: Calcite > Issue Type: Improvement >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > > Update `linq4j` tests upgrade from junit4 to junit5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3637) Update linq4j tests upgrade from junit4 to junit5
Forward Xu created CALCITE-3637: --- Summary: Update linq4j tests upgrade from junit4 to junit5 Key: CALCITE-3637 URL: https://issues.apache.org/jira/browse/CALCITE-3637 Project: Calcite Issue Type: Improvement Reporter: Forward Xu Update `linq4j` tests upgrade from junit4 to junit5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3636) Implement RelHint for Sort
[ https://issues.apache.org/jira/browse/CALCITE-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3636: Labels: pull-request-available (was: ) > Implement RelHint for Sort > --- > > Key: CALCITE-3636 > URL: https://issues.apache.org/jira/browse/CALCITE-3636 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3636) Implement RelHint for Sort
xzh_dz created CALCITE-3636: --- Summary: Implement RelHint for Sort Key: CALCITE-3636 URL: https://issues.apache.org/jira/browse/CALCITE-3636 Project: Calcite Issue Type: Wish Reporter: xzh_dz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3635) Supports hint option as string or numeric literal
[
https://issues.apache.org/jira/browse/CALCITE-3635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3635:
Labels: pull-request-available (was: )
> Supports hint option as string or numeric literal
> -
>
> Key: CALCITE-3635
> URL: https://issues.apache.org/jira/browse/CALCITE-3635
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.21.0
>Reporter: Danny Chen
>Assignee: Danny Chen
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.22.0
>
>
> Support hint item syntax as:
> {code:sql}
> select /*+ time_zone(1, 1.23, 'a bc', -1.0) */ * from emp
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3635) Supports hint option as string or numeric literal
Danny Chen created CALCITE-3635:
---
Summary: Supports hint option as string or numeric literal
Key: CALCITE-3635
URL: https://issues.apache.org/jira/browse/CALCITE-3635
Project: Calcite
Issue Type: Improvement
Components: core
Affects Versions: 1.21.0
Reporter: Danny Chen
Assignee: Danny Chen
Fix For: 1.22.0
Support hint item syntax as:
{code:sql}
select /*+ time_zone(1, 1.23, 'a bc', -1.0) */ * from emp
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3606) batch insert failed
[
https://issues.apache.org/jira/browse/CALCITE-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003595#comment-17003595
]
Jin Xing commented on CALCITE-3606:
---
Hi Ran ~
I proposed a PR to fix the case you provided ~
Please check ~
Jin
> batch insert failed
> ---
>
> Key: CALCITE-3606
> URL: https://issues.apache.org/jira/browse/CALCITE-3606
> Project: Calcite
> Issue Type: Wish
> Components: core
>Affects Versions: 1.21.0
>Reporter: Ran Cao
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> when I try to execute sql like (insert into example_table (column1,column2)
> values (value1,value2),(value1,value2)), it will failed with error message
> like this: column "EXPR$0" of relation "example_table" does not exist. I find
> the reason is that when converting SqlNode(insert sql) to
> RelNode(TableModify), one of the steps is to change the column that stored in
> RelDataType from the fake column name (like "EXPR$0") to the real column name
> (like "id"). But when the values part in sql is more than one , the step
> above-mentioned will skip because the RelNode is instance of LogicalUnion
> instead of Project, the code refered to org.apache.calcite.tools.RelBuilder
> line 1461:
> if (input instanceof Project && fieldNames != null) {
> // change the column name
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3634) Support Intersect and Minus on Calcs for materialized view recognition
[ https://issues.apache.org/jira/browse/CALCITE-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3634: Labels: pull-request-available (was: ) > Support Intersect and Minus on Calcs for materialized view recognition > -- > > Key: CALCITE-3634 > URL: https://issues.apache.org/jira/browse/CALCITE-3634 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > > IntersectOnCalcsToIntersectUnifyRule and MinusOnCalcsToMinus is not > implemented in SubstitutionVisitor, this pr try to implement it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3634) Support Intersect and Minus on Calcs for materialized view recognition
xzh_dz created CALCITE-3634: --- Summary: Support Intersect and Minus on Calcs for materialized view recognition Key: CALCITE-3634 URL: https://issues.apache.org/jira/browse/CALCITE-3634 Project: Calcite Issue Type: Wish Reporter: xzh_dz IntersectOnCalcsToIntersectUnifyRule and MinusOnCalcsToMinus is not implemented in SubstitutionVisitor, this pr try to implement it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (CALCITE-2935) Support ANY, SOME, EVERY (also known as BOOL_OR, BOOL_AND) aggregate functions
[ https://issues.apache.org/jira/browse/CALCITE-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen reassigned CALCITE-2935: --- Assignee: Danny Chen > Support ANY, SOME, EVERY (also known as BOOL_OR, BOOL_AND) aggregate > functions > --- > > Key: CALCITE-2935 > URL: https://issues.apache.org/jira/browse/CALCITE-2935 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Haisheng Yuan >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > ANY, SOME is equivalent with bool_or. EVERY is equivalent with bool_and. > Parser needs to be changed to support these aggregate functions. > https://blog.jooq.org/2014/12/18/a-true-sql-gem-you-didnt-know-yet-the-every-aggregate-function/ > https://mysqlserverteam.com/using-the-aggregate-functions-any-some-every-with-mysql/ > Note that if ANY or SOME aggregate function is placed on the right side of > comparison operation and argument of this function is a subquery additional > parentheses around aggregate function are required, otherwise it will be > parsed as quantified comparison predicate. > Example: > ANY(NAME LIKE 'W%') > A = (ANY((SELECT B FROM T))) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3628) OOB when using CallCopyingArgHandler to copy sql nodes with hint
[
https://issues.apache.org/jira/browse/CALCITE-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Axis resolved CALCITE-3628.
---
Resolution: Fixed
it is already fix now in : https://issues.apache.org/jira/browse/CALCITE-3590
> OOB when using CallCopyingArgHandler to copy sql nodes with hint
>
>
> Key: CALCITE-3628
> URL: https://issues.apache.org/jira/browse/CALCITE-3628
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Axis
>Priority: Critical
> Fix For: 1.22.0
>
>
> Hello,
> When we use the CallCopyingArgHandler to copy the sql node tree, we will
> get OOB.
> {code:java}
> java.lang.ArrayIndexOutOfBoundsException: 10
> at org.apache.calcite.sql.SqlSelectOperator.createCall
> ...{code}
>
> I find calcite has been supported SqlHint in commit
> (bf40ad33e7ee85ff426ddc493fe6d9a5bfe6a208).
> And the function createCall in SqlSelect has been changed:
> {code:java}
> public class SqlSelectOperator extends SqlOperator {
> public static final SqlSelectOperator INSTANCE =
> new SqlSelectOperator();
> //~ Constructors ---
> private SqlSelectOperator() {
> super("SELECT", SqlKind.SELECT, 2, true, ReturnTypes.SCOPE, null, null);
> }
> //~ Methods
> public SqlSyntax getSyntax() {
> return SqlSyntax.SPECIAL;
> }
> public SqlCall createCall(
> SqlLiteral functionQualifier,
> SqlParserPos pos,
> SqlNode... operands) {
> assert functionQualifier == null;
> return new SqlSelect(pos,
> (SqlNodeList) operands[0],
> (SqlNodeList) operands[1],
> operands[2],
> operands[3],
> (SqlNodeList) operands[4],
> operands[5],
> (SqlNodeList) operands[6],
> (SqlNodeList) operands[7],
> operands[8],
> operands[9],
> (SqlNodeList) operands[10]); --> Sql hints array
> } {code}
> operator[10] might be SqlHints array in SqlSelect.
> When developer wants to copy the sql node tree using CallCopyingArgHandler.
> It will call the follow the code:
> {code:java}
> protected class CallCopyingArgHandler implements ArgHandler {
> boolean update;
> SqlNode[] clonedOperands;
> private final SqlCall call;
> private final boolean alwaysCopy;
> public CallCopyingArgHandler(SqlCall call, boolean alwaysCopy) {
> this.call = call;
> this.update = false;
> final List operands = call.getOperandList();---> sqlSelect
> operators
> this.clonedOperands = operands.toArray(new SqlNode[0]);
> this.alwaysCopy = alwaysCopy;
> }
> public SqlNode result() {
> if (update || alwaysCopy) {
> return call.getOperator().createCall(
> call.getFunctionQuantifier(),
> call.getParserPosition(),
> clonedOperands); --> SqlSelect operstors
> } else {
> return call;
> }
> }
> {code}
> When the code invoke the "result" method, it will call the
> SqlSelect::createCall, and pass the call.getOperandList as the dynamic
> params. But SqlSelect's operator only have 10 operators (not contain hints)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-3628) OOB when using CallCopyingArgHandler to copy sql nodes with hint
[
https://issues.apache.org/jira/browse/CALCITE-3628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003553#comment-17003553
]
Axis commented on CALCITE-3628:
---
yes, it already fix
> OOB when using CallCopyingArgHandler to copy sql nodes with hint
>
>
> Key: CALCITE-3628
> URL: https://issues.apache.org/jira/browse/CALCITE-3628
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.22.0
>Reporter: Axis
>Priority: Critical
> Fix For: 1.22.0
>
>
> Hello,
> When we use the CallCopyingArgHandler to copy the sql node tree, we will
> get OOB.
> {code:java}
> java.lang.ArrayIndexOutOfBoundsException: 10
> at org.apache.calcite.sql.SqlSelectOperator.createCall
> ...{code}
>
> I find calcite has been supported SqlHint in commit
> (bf40ad33e7ee85ff426ddc493fe6d9a5bfe6a208).
> And the function createCall in SqlSelect has been changed:
> {code:java}
> public class SqlSelectOperator extends SqlOperator {
> public static final SqlSelectOperator INSTANCE =
> new SqlSelectOperator();
> //~ Constructors ---
> private SqlSelectOperator() {
> super("SELECT", SqlKind.SELECT, 2, true, ReturnTypes.SCOPE, null, null);
> }
> //~ Methods
> public SqlSyntax getSyntax() {
> return SqlSyntax.SPECIAL;
> }
> public SqlCall createCall(
> SqlLiteral functionQualifier,
> SqlParserPos pos,
> SqlNode... operands) {
> assert functionQualifier == null;
> return new SqlSelect(pos,
> (SqlNodeList) operands[0],
> (SqlNodeList) operands[1],
> operands[2],
> operands[3],
> (SqlNodeList) operands[4],
> operands[5],
> (SqlNodeList) operands[6],
> (SqlNodeList) operands[7],
> operands[8],
> operands[9],
> (SqlNodeList) operands[10]); --> Sql hints array
> } {code}
> operator[10] might be SqlHints array in SqlSelect.
> When developer wants to copy the sql node tree using CallCopyingArgHandler.
> It will call the follow the code:
> {code:java}
> protected class CallCopyingArgHandler implements ArgHandler {
> boolean update;
> SqlNode[] clonedOperands;
> private final SqlCall call;
> private final boolean alwaysCopy;
> public CallCopyingArgHandler(SqlCall call, boolean alwaysCopy) {
> this.call = call;
> this.update = false;
> final List operands = call.getOperandList();---> sqlSelect
> operators
> this.clonedOperands = operands.toArray(new SqlNode[0]);
> this.alwaysCopy = alwaysCopy;
> }
> public SqlNode result() {
> if (update || alwaysCopy) {
> return call.getOperator().createCall(
> call.getFunctionQuantifier(),
> call.getParserPosition(),
> clonedOperands); --> SqlSelect operstors
> } else {
> return call;
> }
> }
> {code}
> When the code invoke the "result" method, it will call the
> SqlSelect::createCall, and pass the call.getOperandList as the dynamic
> params. But SqlSelect's operator only have 10 operators (not contain hints)
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3606) batch insert failed
[
https://issues.apache.org/jira/browse/CALCITE-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3606:
Labels: pull-request-available (was: )
> batch insert failed
> ---
>
> Key: CALCITE-3606
> URL: https://issues.apache.org/jira/browse/CALCITE-3606
> Project: Calcite
> Issue Type: Wish
> Components: core
>Affects Versions: 1.21.0
>Reporter: Ran Cao
>Priority: Major
> Labels: pull-request-available
>
> when I try to execute sql like (insert into example_table (column1,column2)
> values (value1,value2),(value1,value2)), it will failed with error message
> like this: column "EXPR$0" of relation "example_table" does not exist. I find
> the reason is that when converting SqlNode(insert sql) to
> RelNode(TableModify), one of the steps is to change the column that stored in
> RelDataType from the fake column name (like "EXPR$0") to the real column name
> (like "id"). But when the values part in sql is more than one , the step
> above-mentioned will skip because the RelNode is instance of LogicalUnion
> instead of Project, the code refered to org.apache.calcite.tools.RelBuilder
> line 1461:
> if (input instanceof Project && fieldNames != null) {
> // change the column name
> }
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-2935) Support ANY, SOME, EVERY (also known as BOOL_OR, BOOL_AND) aggregate functions
[ https://issues.apache.org/jira/browse/CALCITE-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-2935: Labels: pull-request-available (was: ) > Support ANY, SOME, EVERY (also known as BOOL_OR, BOOL_AND) aggregate > functions > --- > > Key: CALCITE-2935 > URL: https://issues.apache.org/jira/browse/CALCITE-2935 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Haisheng Yuan >Priority: Major > Labels: pull-request-available > > ANY, SOME is equivalent with bool_or. EVERY is equivalent with bool_and. > Parser needs to be changed to support these aggregate functions. > https://blog.jooq.org/2014/12/18/a-true-sql-gem-you-didnt-know-yet-the-every-aggregate-function/ > https://mysqlserverteam.com/using-the-aggregate-functions-any-some-every-with-mysql/ > Note that if ANY or SOME aggregate function is placed on the right side of > comparison operation and argument of this function is a subquery additional > parentheses around aggregate function are required, otherwise it will be > parsed as quantified comparison predicate. > Example: > ANY(NAME LIKE 'W%') > A = (ANY((SELECT B FROM T))) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3617) Add BOOL_OR Aggregate Function
[ https://issues.apache.org/jira/browse/CALCITE-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003528#comment-17003528 ] Haisheng Yuan commented on CALCITE-3617: Thanks , you can take it. > Add BOOL_OR Aggregate Function > -- > > Key: CALCITE-3617 > URL: https://issues.apache.org/jira/browse/CALCITE-3617 > Project: Calcite > Issue Type: New Feature >Reporter: Ritesh >Priority: Major > > [https://docs.aws.amazon.com/redshift/latest/dg/r_BOOL_OR.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-2935) Support ANY, SOME, EVERY (also known as BOOL_OR, BOOL_AND) aggregate functions
[ https://issues.apache.org/jira/browse/CALCITE-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003524#comment-17003524 ] ShuMing Li commented on CALCITE-2935: - +Note that BOOL_OR and BOOL_AND will essentially be aliases for MAX and MIN.+ Yep. But BOOL_OR/BOOL_AND only support a `boolean` type input which it's different with MIN/MAX. There are duplicated issues: https://issues.apache.org/jira/browse/CALCITE-3616 https://issues.apache.org/jira/browse/CALCITE-3617 > Support ANY, SOME, EVERY (also known as BOOL_OR, BOOL_AND) aggregate > functions > --- > > Key: CALCITE-2935 > URL: https://issues.apache.org/jira/browse/CALCITE-2935 > Project: Calcite > Issue Type: New Feature > Components: core >Reporter: Haisheng Yuan >Priority: Major > > ANY, SOME is equivalent with bool_or. EVERY is equivalent with bool_and. > Parser needs to be changed to support these aggregate functions. > https://blog.jooq.org/2014/12/18/a-true-sql-gem-you-didnt-know-yet-the-every-aggregate-function/ > https://mysqlserverteam.com/using-the-aggregate-functions-any-some-every-with-mysql/ > Note that if ANY or SOME aggregate function is placed on the right side of > comparison operation and argument of this function is a subquery additional > parentheses around aggregate function are required, otherwise it will be > parsed as quantified comparison predicate. > Example: > ANY(NAME LIKE 'W%') > A = (ANY((SELECT B FROM T))) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3617) Add BOOL_OR Aggregate Function
[ https://issues.apache.org/jira/browse/CALCITE-3617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003521#comment-17003521 ] ShuMing Li commented on CALCITE-3617: - Can I work on this issue? BTW, It's duplicated with [CALCITE-2935](https://issues.apache.org/jira/browse/CALCITE-2935). > Add BOOL_OR Aggregate Function > -- > > Key: CALCITE-3617 > URL: https://issues.apache.org/jira/browse/CALCITE-3617 > Project: Calcite > Issue Type: New Feature >Reporter: Ritesh >Priority: Major > > [https://docs.aws.amazon.com/redshift/latest/dg/r_BOOL_OR.html] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3633) Update Cassandra tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3633: Labels: pull-request-available (was: ) > Update Cassandra tests upgrade from junit4 to junit5 > > > Key: CALCITE-3633 > URL: https://issues.apache.org/jira/browse/CALCITE-3633 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3633) Update Cassandra tests upgrade from junit4 to junit5
xzh_dz created CALCITE-3633: --- Summary: Update Cassandra tests upgrade from junit4 to junit5 Key: CALCITE-3633 URL: https://issues.apache.org/jira/browse/CALCITE-3633 Project: Calcite Issue Type: Wish Reporter: xzh_dz -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3622) Update geode tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17003516#comment-17003516 ] Vladimir Sitnikov commented on CALCITE-3622: Fixed in https://github.com/apache/calcite/commit/484b112641a1a9780bafc43cda6079ebc4806ca3 > Update geode tests upgrade from junit4 to junit5 > > > Key: CALCITE-3622 > URL: https://issues.apache.org/jira/browse/CALCITE-3622 > Project: Calcite > Issue Type: Improvement > Components: geode-adapter >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update `geode` tests upgrade from junit4 to junit5. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3625) Update mongo tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3625: --- Fix Version/s: 1.22.0 > Update mongo tests upgrade from junit4 to junit5 > > > Key: CALCITE-3625 > URL: https://issues.apache.org/jira/browse/CALCITE-3625 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Update `mongo` tests upgrade from junit4 to junit5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3625) Update mongo tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov resolved CALCITE-3625. Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/e50f5338fbd1779f0cb41ce66a8f6a8c8f6c3034 > Update mongo tests upgrade from junit4 to junit5 > > > Key: CALCITE-3625 > URL: https://issues.apache.org/jira/browse/CALCITE-3625 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Update `mongo` tests upgrade from junit4 to junit5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3601) Update elasticsearch tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov resolved CALCITE-3601. Resolution: Fixed Fixed in https://github.com/apache/calcite/commit/4415171f52cd31f310bb06604a5781d92ad2105d > Update elasticsearch tests upgrade from junit4 to junit5 > > > Key: CALCITE-3601 > URL: https://issues.apache.org/jira/browse/CALCITE-3601 > Project: Calcite > Issue Type: Test > Components: elasticsearch-adapter >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Update `elasticsearch` tests upgrade from junit4 to junit5. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3625) Update mongo tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3625: --- Component/s: mongodb-adapter > Update mongo tests upgrade from junit4 to junit5 > > > Key: CALCITE-3625 > URL: https://issues.apache.org/jira/browse/CALCITE-3625 > Project: Calcite > Issue Type: Improvement > Components: mongodb-adapter >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Update `mongo` tests upgrade from junit4 to junit5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3601) Update elasticsearch tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3601: --- Component/s: elasticsearch-adapter > Update elasticsearch tests upgrade from junit4 to junit5 > > > Key: CALCITE-3601 > URL: https://issues.apache.org/jira/browse/CALCITE-3601 > Project: Calcite > Issue Type: Test > Components: elasticsearch-adapter >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Update `elasticsearch` tests upgrade from junit4 to junit5. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3601) Update elasticsearch tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3601: --- Fix Version/s: 1.22.0 > Update elasticsearch tests upgrade from junit4 to junit5 > > > Key: CALCITE-3601 > URL: https://issues.apache.org/jira/browse/CALCITE-3601 > Project: Calcite > Issue Type: Test >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > Update `elasticsearch` tests upgrade from junit4 to junit5. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3622) Update geode tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3622: --- Fix Version/s: 1.22.0 > Update geode tests upgrade from junit4 to junit5 > > > Key: CALCITE-3622 > URL: https://issues.apache.org/jira/browse/CALCITE-3622 > Project: Calcite > Issue Type: Improvement >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update `geode` tests upgrade from junit4 to junit5. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3622) Update geode tests upgrade from junit4 to junit5
[ https://issues.apache.org/jira/browse/CALCITE-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Sitnikov updated CALCITE-3622: --- Component/s: geode-adapter > Update geode tests upgrade from junit4 to junit5 > > > Key: CALCITE-3622 > URL: https://issues.apache.org/jira/browse/CALCITE-3622 > Project: Calcite > Issue Type: Improvement > Components: geode-adapter >Reporter: Forward Xu >Assignee: Forward Xu >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update `geode` tests upgrade from junit4 to junit5. -- This message was sent by Atlassian Jira (v8.3.4#803005)
