[jira] [Commented] (CALCITE-2707) Information about distinct aggregation is lost in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-2707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932181#comment-16932181
]
Danny Chan commented on CALCITE-2707:
-
When can we fix this issue, there is a copy file of Calcite SqlValidatorImpl in
flink-table-planner, and there is no change to patch other Calcite bug fix in
the validator, we should solve this issue as soon as possible and remove the
file SqlValidatorImpl.java.
> Information about distinct aggregation is lost in MATCH_RECOGNIZE
> -
>
> Key: CALCITE-2707
> URL: https://issues.apache.org/jira/browse/CALCITE-2707
> Project: Calcite
> Issue Type: Bug
>Reporter: Dawid Wysakowicz
>Priority: Major
> Labels: match
>
> There is no information that the COUNT aggregation is distinct in a plan for
> a query like e.g. this:
> {code}
> SELECT *
> FROM MyTable
> MATCH_RECOGNIZE (
> MEASURES
>
> AFTER MATCH SKIP PAST LAST ROW
> PATTERN (A B+ C)
> DEFINE
> B AS COUNT(DISTINCT B.id) < 4
> ) AS T
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3320) Use x/xerrors package when working with errors
[
https://issues.apache.org/jira/browse/CALCITE-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-3320:
Summary: Use x/xerrors package when working with errors (was: Use error
wrapping in stdlib)
> Use x/xerrors package when working with errors
> --
>
> Key: CALCITE-3320
> URL: https://issues.apache.org/jira/browse/CALCITE-3320
> Project: Calcite
> Issue Type: Improvement
> Components: avatica-go
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Major
>
> In Go 1.13, it's possible to wrap errors using `fmt.Errorf("%w", err)`.
> We need to update places where errors are wrapped to use the `%w`
> placeholder.
> Use the golang.org/x/xerrors for compatibility with Go versions before 1.13.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3320) Use x/xerrors package when working with errors
[
https://issues.apache.org/jira/browse/CALCITE-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3320:
Labels: pull-request-available (was: )
> Use x/xerrors package when working with errors
> --
>
> Key: CALCITE-3320
> URL: https://issues.apache.org/jira/browse/CALCITE-3320
> Project: Calcite
> Issue Type: Improvement
> Components: avatica-go
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Major
> Labels: pull-request-available
>
> In Go 1.13, it's possible to wrap errors using `fmt.Errorf("%w", err)`.
> We need to update places where errors are wrapped to use the `%w`
> placeholder.
> Use the golang.org/x/xerrors for compatibility with Go versions before 1.13.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3359) Update dependencies
Francis Chuang created CALCITE-3359: --- Summary: Update dependencies Key: CALCITE-3359 URL: https://issues.apache.org/jira/browse/CALCITE-3359 Project: Calcite Issue Type: Improvement Components: avatica-go Reporter: Francis Chuang Assignee: Francis Chuang Fix For: avatica-go-5.0.0 Update dependencies before releasing 5.0.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3320) Use x/xerrors package when working with errors
[
https://issues.apache.org/jira/browse/CALCITE-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang updated CALCITE-3320:
Fix Version/s: avatica-go-5.0.0
> Use x/xerrors package when working with errors
> --
>
> Key: CALCITE-3320
> URL: https://issues.apache.org/jira/browse/CALCITE-3320
> Project: Calcite
> Issue Type: Improvement
> Components: avatica-go
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-go-5.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Go 1.13, it's possible to wrap errors using `fmt.Errorf("%w", err)`.
> We need to update places where errors are wrapped to use the `%w`
> placeholder.
> Use the golang.org/x/xerrors for compatibility with Go versions before 1.13.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (CALCITE-3320) Use x/xerrors package when working with errors
[
https://issues.apache.org/jira/browse/CALCITE-3320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francis Chuang resolved CALCITE-3320.
-
Resolution: Fixed
> Use x/xerrors package when working with errors
> --
>
> Key: CALCITE-3320
> URL: https://issues.apache.org/jira/browse/CALCITE-3320
> Project: Calcite
> Issue Type: Improvement
> Components: avatica-go
>Reporter: Francis Chuang
>Assignee: Francis Chuang
>Priority: Major
> Labels: pull-request-available
> Fix For: avatica-go-5.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In Go 1.13, it's possible to wrap errors using `fmt.Errorf("%w", err)`.
> We need to update places where errors are wrapped to use the `%w`
> placeholder.
> Use the golang.org/x/xerrors for compatibility with Go versions before 1.13.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-2405) In Babel parser: allow to use some reserved keyword as identifier
[ https://issues.apache.org/jira/browse/CALCITE-2405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932171#comment-16932171 ] Enrico Olivelli commented on CALCITE-2405: -- [~julianhyde] do you think it is feasible to add 'timestamp' ? is there any extension point to allow that keyword as nonReservedKeyword only in my project ? > In Babel parser: allow to use some reserved keyword as identifier > - > > Key: CALCITE-2405 > URL: https://issues.apache.org/jira/browse/CALCITE-2405 > Project: Calcite > Issue Type: New Feature > Components: babel >Affects Versions: 1.17.0 >Reporter: Enrico Olivelli >Assignee: Julian Hyde >Priority: Major > Fix For: 1.18.0 > > > I have some case of incompatibility between MySQL (actually on HerdDB which > is a replacement for MySQL) and Calcite around reserved identifiers. > * Allow a schema with name 'default' > * Allow a column name with name 'value' > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3353) ProjectJoinTransposeRule caused AssertionError when creating a new Join
[
https://issues.apache.org/jira/browse/CALCITE-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932413#comment-16932413
]
TANG Wen-hui edited comment on CALCITE-3353 at 9/18/19 1:00 PM:
[~danny0405]，Yes, "forbidden to match convention(non-logical) nodes" is one way
to fix the bug or we can use RelFactories.DEFAULT_JOIN_FACTORY.createJoin()
instead of Join.copy() to create new Join.
was (Author: winipanda):
[~danny0405]，Yes, "forbidden to match convention(non-logical) nodes" is one way
to fix the bug or we can use RelFactories.DEFAULT_JOIN_FACTORY.createJoin()
instead of Join.copty() to create new Join.
> ProjectJoinTransposeRule caused AssertionError when creating a new Join
> ---
>
> Key: CALCITE-3353
> URL: https://issues.apache.org/jira/browse/CALCITE-3353
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: TANG Wen-hui
>Assignee: TANG Wen-hui
>Priority: Major
>
> Trying to add ProjectJoinTransposeRule to the rule set to optimize sql (using
> VolcanoPlanner).
> Get the following exception：
> Caused by: java.lang.AssertionErrorCaused by: java.lang.AssertionError at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.(EnumerableMergeJoin.java:72)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:112)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:59)
> at
> org.apache.calcite.rel.rules.ProjectJoinTransposeRule.onMatch(ProjectJoinTransposeRule.java:155)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:703)
> at org.apache.calcite.tools.Programs.lambda$standard$7(Programs.java:466) at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:528) at
> org.apache.calcite.prepare.Prepare.optimize(Prepare.java:196) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:416) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:310) at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:830)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:580)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:247)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:711)
>
> ... 22 more
> This is because the ProjectJoinTransposeRule can match multiple types of Join
> and ProjectJoinTransposeRule creates a new Join using the join.copy() method.
> When the rule applied to EnumerableMergeJoin, and the new Join created by
> this rule may not meet the requirements of EnumerableMergeJoin.
> {code:java}
> EnumerableMergeJoin(
> RelOptCluster cluster,
> RelTraitSet traits,
> RelNode left,
> RelNode right,
> RexNode condition,
> Set variablesSet,
> JoinRelType joinType) {
> super(cluster, traits, left, right, condition, variablesSet, joinType);
> final List collations =
> traits.getTraits(RelCollationTraitDef.INSTANCE);
> assert collations == null || RelCollations.contains(collations,
> joinInfo.leftKeys);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CALCITE-3360) SqlValidator throws NEP for unregistered function without implicit type coercion
Danny Chan created CALCITE-3360: --- Summary: SqlValidator throws NEP for unregistered function without implicit type coercion Key: CALCITE-3360 URL: https://issues.apache.org/jira/browse/CALCITE-3360 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.21.0 Reporter: Danny Chan Assignee: Danny Chan Fix For: 1.22.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3353) ProjectJoinTransposeRule caused AssertionError when creating a new Join
[
https://issues.apache.org/jira/browse/CALCITE-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932413#comment-16932413
]
TANG Wen-hui commented on CALCITE-3353:
---
[~danny0405]，Yes, "forbidden to match convention(non-logical) nodes" is one way
to fix the bug or we can use RelFactories.DEFAULT_JOIN_FACTORY.createJoin()
other than Join.copty() to create new Join.
> ProjectJoinTransposeRule caused AssertionError when creating a new Join
> ---
>
> Key: CALCITE-3353
> URL: https://issues.apache.org/jira/browse/CALCITE-3353
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: TANG Wen-hui
>Assignee: TANG Wen-hui
>Priority: Major
>
> Trying to add ProjectJoinTransposeRule to the rule set to optimize sql (using
> VolcanoPlanner).
> Get the following exception：
> Caused by: java.lang.AssertionErrorCaused by: java.lang.AssertionError at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.(EnumerableMergeJoin.java:72)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:112)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:59)
> at
> org.apache.calcite.rel.rules.ProjectJoinTransposeRule.onMatch(ProjectJoinTransposeRule.java:155)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:703)
> at org.apache.calcite.tools.Programs.lambda$standard$7(Programs.java:466) at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:528) at
> org.apache.calcite.prepare.Prepare.optimize(Prepare.java:196) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:416) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:310) at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:830)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:580)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:247)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:711)
>
> ... 22 more
> This is because the ProjectJoinTransposeRule can match multiple types of Join
> and ProjectJoinTransposeRule creates a new Join using the join.copy() method.
> When the rule applied to EnumerableMergeJoin, and the new Join created by
> this rule may not meet the requirements of EnumerableMergeJoin.
> {code:java}
> EnumerableMergeJoin(
> RelOptCluster cluster,
> RelTraitSet traits,
> RelNode left,
> RelNode right,
> RexNode condition,
> Set variablesSet,
> JoinRelType joinType) {
> super(cluster, traits, left, right, condition, variablesSet, joinType);
> final List collations =
> traits.getTraits(RelCollationTraitDef.INSTANCE);
> assert collations == null || RelCollations.contains(collations,
> joinInfo.leftKeys);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3353) ProjectJoinTransposeRule caused AssertionError when creating a new Join
[
https://issues.apache.org/jira/browse/CALCITE-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932413#comment-16932413
]
TANG Wen-hui edited comment on CALCITE-3353 at 9/18/19 12:59 PM:
-
[~danny0405]，Yes, "forbidden to match convention(non-logical) nodes" is one way
to fix the bug or we can use RelFactories.DEFAULT_JOIN_FACTORY.createJoin()
instead of Join.copty() to create new Join.
was (Author: winipanda):
[~danny0405]，Yes, "forbidden to match convention(non-logical) nodes" is one way
to fix the bug or we can use RelFactories.DEFAULT_JOIN_FACTORY.createJoin()
other than Join.copty() to create new Join.
> ProjectJoinTransposeRule caused AssertionError when creating a new Join
> ---
>
> Key: CALCITE-3353
> URL: https://issues.apache.org/jira/browse/CALCITE-3353
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: TANG Wen-hui
>Assignee: TANG Wen-hui
>Priority: Major
>
> Trying to add ProjectJoinTransposeRule to the rule set to optimize sql (using
> VolcanoPlanner).
> Get the following exception：
> Caused by: java.lang.AssertionErrorCaused by: java.lang.AssertionError at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.(EnumerableMergeJoin.java:72)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:112)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:59)
> at
> org.apache.calcite.rel.rules.ProjectJoinTransposeRule.onMatch(ProjectJoinTransposeRule.java:155)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:703)
> at org.apache.calcite.tools.Programs.lambda$standard$7(Programs.java:466) at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:528) at
> org.apache.calcite.prepare.Prepare.optimize(Prepare.java:196) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:416) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:310) at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:830)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:580)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:247)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:711)
>
> ... 22 more
> This is because the ProjectJoinTransposeRule can match multiple types of Join
> and ProjectJoinTransposeRule creates a new Join using the join.copy() method.
> When the rule applied to EnumerableMergeJoin, and the new Join created by
> this rule may not meet the requirements of EnumerableMergeJoin.
> {code:java}
> EnumerableMergeJoin(
> RelOptCluster cluster,
> RelTraitSet traits,
> RelNode left,
> RelNode right,
> RexNode condition,
> Set variablesSet,
> JoinRelType joinType) {
> super(cluster, traits, left, right, condition, variablesSet, joinType);
> final List collations =
> traits.getTraits(RelCollationTraitDef.INSTANCE);
> assert collations == null || RelCollations.contains(collations,
> joinInfo.leftKeys);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-1178) Allow SqlBetweenOperator to compare DATE and TIMESTAMP
[
https://issues.apache.org/jira/browse/CALCITE-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932382#comment-16932382
]
Jacob Roldan commented on CALCITE-1178:
---
Since calcite 1.21 it's possible to do
{code:sql}
date '1999-03-02' < timestamp '1999-03-03 00:00:00.0'
{code}
but not with {{_between_}}
I don't know if it's a feature (I haven't seen anything in the release note) or
if it's a bug
> Allow SqlBetweenOperator to compare DATE and TIMESTAMP
> --
>
> Key: CALCITE-1178
> URL: https://issues.apache.org/jira/browse/CALCITE-1178
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sean Hsuan-Yi Chu
>Assignee: Sean Hsuan-Yi Chu
>Priority: Major
>
> An expression such as
> {code}
> date '1999-03-02' between date '1999-03-01' and timestamp '1999-03-03
> 00:00:00.0'
> {code}
> will incur SqlValidatorException since SqlBetweenOperator does not allow DATE
> and TIMESTAMP comparison. In terms of usability, it would be great if this
> type of comparison is allowed in Calcite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3353) ProjectJoinTransposeRule caused AssertionError when creating a new Join
[
https://issues.apache.org/jira/browse/CALCITE-3353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-3353:
Labels: pull-request-available (was: )
> ProjectJoinTransposeRule caused AssertionError when creating a new Join
> ---
>
> Key: CALCITE-3353
> URL: https://issues.apache.org/jira/browse/CALCITE-3353
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.20.0
>Reporter: TANG Wen-hui
>Assignee: TANG Wen-hui
>Priority: Major
> Labels: pull-request-available
>
> Trying to add ProjectJoinTransposeRule to the rule set to optimize sql (using
> VolcanoPlanner).
> Get the following exception：
> Caused by: java.lang.AssertionErrorCaused by: java.lang.AssertionError at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.(EnumerableMergeJoin.java:72)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:112)
> at
> org.apache.calcite.adapter.enumerable.EnumerableMergeJoin.copy(EnumerableMergeJoin.java:59)
> at
> org.apache.calcite.rel.rules.ProjectJoinTransposeRule.onMatch(ProjectJoinTransposeRule.java:155)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:208)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:703)
> at org.apache.calcite.tools.Programs.lambda$standard$7(Programs.java:466) at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:528) at
> org.apache.calcite.prepare.Prepare.optimize(Prepare.java:196) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:416) at
> org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:310) at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:830)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:580)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:247)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:711)
>
> ... 22 more
> This is because the ProjectJoinTransposeRule can match multiple types of Join
> and ProjectJoinTransposeRule creates a new Join using the join.copy() method.
> When the rule applied to EnumerableMergeJoin, and the new Join created by
> this rule may not meet the requirements of EnumerableMergeJoin.
> {code:java}
> EnumerableMergeJoin(
> RelOptCluster cluster,
> RelTraitSet traits,
> RelNode left,
> RelNode right,
> RexNode condition,
> Set variablesSet,
> JoinRelType joinType) {
> super(cluster, traits, left, right, condition, variablesSet, joinType);
> final List collations =
> traits.getTraits(RelCollationTraitDef.INSTANCE);
> assert collations == null || RelCollations.contains(collations,
> joinInfo.leftKeys);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated CALCITE-963:
---
Labels: pull-request-available (was: )
> Hoist literals
> --
>
> Key: CALCITE-963
> URL: https://issues.apache.org/jira/browse/CALCITE-963
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
>
> Convert literals into (internal) bind variables so that statements that
> differ only in literal values can be executed using the same plan.
> In [mail
> thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201511.mbox/%3c56437bf8.70...@gmail.com%3E]
> Homer wrote:
> {quote}Imagine that it is common to run a large number of very similar
> machine generated queries that just change the literals in the sql query.
> For example (the real queries would be much more complex):
> {code}Select * from emp where empno = 1;
> Select * from emp where empno = 2;
> etc.{code}
> The plan that is likely being generated for these kind of queries is going to
> be very much the same each time, so to save some time, I would like to
> recognize that the literals are all that have changed in a query and use the
> previously optimized execution plan and just replace the literals.{quote}
> I think this could be done as a transform on the initial RelNode tree. It
> would find literals (RexLiteral), replace them with bind variables
> (RexDynamicParam) and write the value into a pool. The next statement would
> go through the same process and the RelNode tree would be identical, but with
> possibly different values for the bind variables.
> The bind variables are of course internal; not visible from JDBC. When the
> statement is executed, the bind variables are implicitly bound.
> Statements would be held in a Guava cache.
> This would be enabled by a config parameter. Unfortunately I don't think we
> could do this by default -- we'd lose optimization power because we would no
> longer be able to do constant reduction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Reynolds updated CALCITE-963:
---
Attachment: (was: HoistedVariables.png)
> Hoist literals
> --
>
> Key: CALCITE-963
> URL: https://issues.apache.org/jira/browse/CALCITE-963
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Attachments: HoistedVariables.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Convert literals into (internal) bind variables so that statements that
> differ only in literal values can be executed using the same plan.
> In [mail
> thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201511.mbox/%3c56437bf8.70...@gmail.com%3E]
> Homer wrote:
> {quote}Imagine that it is common to run a large number of very similar
> machine generated queries that just change the literals in the sql query.
> For example (the real queries would be much more complex):
> {code}Select * from emp where empno = 1;
> Select * from emp where empno = 2;
> etc.{code}
> The plan that is likely being generated for these kind of queries is going to
> be very much the same each time, so to save some time, I would like to
> recognize that the literals are all that have changed in a query and use the
> previously optimized execution plan and just replace the literals.{quote}
> I think this could be done as a transform on the initial RelNode tree. It
> would find literals (RexLiteral), replace them with bind variables
> (RexDynamicParam) and write the value into a pool. The next statement would
> go through the same process and the RelNode tree would be identical, but with
> possibly different values for the bind variables.
> The bind variables are of course internal; not visible from JDBC. When the
> statement is executed, the bind variables are implicitly bound.
> Statements would be held in a Guava cache.
> This would be enabled by a config parameter. Unfortunately I don't think we
> could do this by default -- we'd lose optimization power because we would no
> longer be able to do constant reduction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932829#comment-16932829
]
Scott Reynolds edited comment on CALCITE-963 at 9/18/19 8:57 PM:
-
h1. Goal
When a query is issued to Calcite it is parsed, optimized and then generates a
String of Java Class that implements {{Bindable}}. {{EnumerableInterpretable}}
creates this string and checks to see if that string exists in
{{com.google.common.cache}} and if it doesn't it will call into a Java
compiler. Compilation process can take a considerable amount of time, Apache
Kylin reported 50 to 150ms of additional computation time. Today, Apache
Calcite will generate unique Java Class strings whenever any part of the query
changes. This document details out the design and implementation of a hoisting
technique within Apache Calcite. This design and implementation greatly
increases the cache hit rate of {{EnumerableInterpretable}}'s
{{BINDABLE_CACHE}}.
h1. Non Goals
This implementation is not designed to change the planning process. It does not
transform {{RexLiteral}} into {{RexDynamicParam}}, and doesn't change the cost
calculation of the query.
h1. Implementation Details
After a query has been optimized there are three phases that remaining phases
to the query:
# Generating the Java code
# Binding Hoisted Variables
# Runtime execution via {{Bindable.bind(DataContext, HoistedVariables)}}
Each of these phases will interact with a new class called {{HoistedVariables}}
!HoistedVariables.png!
Each of these methods are used in the above three phases to hoist a variable
from within the query into the runtime execution of the {{Bindable}}.
The method {{implement}} of the interface {{EnumerableRel}} is used to generate
the Java code in phase one. Each of these {{RelNode}} can now call
{{registerVariable(String)}} to allocate a {{Slot}} for their unbound value.
This {{Slot}} is reserved for their use and is unique for the query plan. When
a {{RelNode}} registers a variable it needs to save that {{Slot}} into a
property so it can be referenced in phase 2. This {{Slot}} is then referenced
in code generation by calling {{EnumerableRel.lookupValue}} which returns an
{{Expression}} that will extract the bound value at for the {{Slot}}.
Below is a snippet from {{EnumerableLimit}} implementation of {{implement}}
that uses {{HoistedVariables}}.
{code:java}
Expression v = builder.append("child", result.block);
if (offset != null) {
if (offset instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) offset);
} else {
// Register with Hoisted Variable here
offsetIndex = variables.registerVariable("offset");
v = builder.append(
"offset",
Expressions.call(
v,
BuiltInMethod.SKIP.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(offsetIndex, Integer.class)));
}
}
if (fetch != null) {
if (fetch instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) fetch);
} else {
// Register with Hoisted Variable here
this.fetchIndex = variables.registerVariable("fetch");
v = builder.append(
"fetch",
Expressions.call(
v,
BuiltInMethod.TAKE.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(fetchIndex, Integer.class)));
}
}
{code}
The second phase of the query execution is where registered {{Slots}} get
bound. To this, our change adds a new optional method to {{Bindable}} called
{{hoistVariables}}. This method is where an instance of {{EnumerableRel}}
extracts the values out of the query plan and binds them into the
{{HoistedVariables}} instance just prior to executing the query. Below is
{{EnumerableLimit}} implementation:
{code:java}
@Override public void hoistedVariables(HoistedVariables variables) {
getInputs()
.stream()
.forEach(rel -> {
final EnumerableRel enumerable = (EnumerableRel) rel;
enumerable.hoistedVariables(variables);
});
if (fetchIndex != null) {
// fetchIndex is the registered slot for this variable. Bind fetchIndex to
fetch
variables.setVariable(fetchIndex, RexLiteral.intValue(fetch));
}
if (offsetIndex != null) {
// offsetIndex is the registered slot for this variable. Bind offsetIndex
to offset.
variables.setVariable(offsetIndex, RexLiteral.intValue(offset));
}
}
{code}
To tie these three phases together, {{CalcitePrepareImpl}} needs to setup the
variables when it creates a {{PreparedResult}}:
{code:java}
try {
CatalogReader.THREAD_LOCAL.set(catalogReader);
final SqlConformance conformance = context.config().conformance();
internalParameters.put("_conformance", conformance);
// Get the compiled Bindable instance either from cache or generate a new one.
[jira] [Commented] (CALCITE-1178) Allow SqlBetweenOperator to compare DATE and TIMESTAMP
[
https://issues.apache.org/jira/browse/CALCITE-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932868#comment-16932868
]
Haisheng Yuan commented on CALCITE-1178:
Not a bug. I think it is a yet implemented feature.
> Allow SqlBetweenOperator to compare DATE and TIMESTAMP
> --
>
> Key: CALCITE-1178
> URL: https://issues.apache.org/jira/browse/CALCITE-1178
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Sean Hsuan-Yi Chu
>Assignee: Sean Hsuan-Yi Chu
>Priority: Major
>
> An expression such as
> {code}
> date '1999-03-02' between date '1999-03-01' and timestamp '1999-03-03
> 00:00:00.0'
> {code}
> will incur SqlValidatorException since SqlBetweenOperator does not allow DATE
> and TIMESTAMP comparison. In terms of usability, it would be great if this
> type of comparison is allowed in Calcite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932872#comment-16932872
]
Julian Hyde commented on CALCITE-963:
-
I looked at the PR briefly:
* I was surprised that HoistedVariables was added to so many API calls. Maybe
it could belong to another piece of the preparation context?
* As a plural noun, HoistedVariables is a poor name for a class, in my opinion.
An instance of HoistedVariables is an object (singular) so it will be difficult
to write good javadoc sentences describing it.
* I was surprised that this work touched so much Enumerable code. An
alternative approach would be to transform a RelNode tree, early in the
planning process, transforming some RexLiteral instances into RexDynamicParam.
The rest of the planning process would proceed as if the user had provided a
statement with bind variables. I know you state that this was a non-goal, but
why was it not a goal? It probably would have been a lot simpler, and it would
have worked with conventions besides Enumerable.
> Hoist literals
> --
>
> Key: CALCITE-963
> URL: https://issues.apache.org/jira/browse/CALCITE-963
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Attachments: HoistedVariables.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Convert literals into (internal) bind variables so that statements that
> differ only in literal values can be executed using the same plan.
> In [mail
> thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201511.mbox/%3c56437bf8.70...@gmail.com%3E]
> Homer wrote:
> {quote}Imagine that it is common to run a large number of very similar
> machine generated queries that just change the literals in the sql query.
> For example (the real queries would be much more complex):
> {code}Select * from emp where empno = 1;
> Select * from emp where empno = 2;
> etc.{code}
> The plan that is likely being generated for these kind of queries is going to
> be very much the same each time, so to save some time, I would like to
> recognize that the literals are all that have changed in a query and use the
> previously optimized execution plan and just replace the literals.{quote}
> I think this could be done as a transform on the initial RelNode tree. It
> would find literals (RexLiteral), replace them with bind variables
> (RexDynamicParam) and write the value into a pool. The next statement would
> go through the same process and the RelNode tree would be identical, but with
> possibly different values for the bind variables.
> The bind variables are of course internal; not visible from JDBC. When the
> statement is executed, the bind variables are implicitly bound.
> Statements would be held in a Guava cache.
> This would be enabled by a config parameter. Unfortunately I don't think we
> could do this by default -- we'd lose optimization power because we would no
> longer be able to do constant reduction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932891#comment-16932891
]
Scott Reynolds commented on CALCITE-963:
{quote} * I was surprised that HoistedVariables was added to so many API calls.
Maybe it could belong to another piece of the preparation context{quote}
I was tempted to add it to {{DataContext}}. It does have to land into
{{CalciteSignature}}
{code:java}
public CalciteSignature(String sql,
List parameterList,
Map internalParameters,
RelDataType rowType,
List columns,
Meta.CursorFactory cursorFactory,
CalciteSchema rootSchema,
List collationList,
long maxRowCount,
Bindable bindable,
Meta.StatementType statementType,
HoistedVariables variables) {
super(columns, sql, parameterList, internalParameters, cursorFactory,
statementType);
this.rowType = rowType;
this.rootSchema = rootSchema;
this.collationList = collationList;
this.maxRowCount = maxRowCount;
this.bindable = bindable;
this.variables = variables;
}
public Enumerable enumerable(DataContext dataContext) {
Enumerable enumerable = bindable.bind(dataContext, variables);
if (maxRowCount >= 0) {
// Apply limit. In JDBC 0 means "no limit". But for us, -1 means
// "no limit", and 0 is a valid limit.
enumerable = EnumerableDefaults.take(enumerable, maxRowCount);
}
return enumerable;
}
{code}
{quote}I was surprised that this work touched so much Enumerable code. An
alternative approach would be to transform a RelNode tree, early in the
planning process, transforming some RexLiteral instances into RexDynamicParam.
The rest of the planning process would proceed as if the user had provided a
statement with bind variables. I know you state that this was a non-goal, but
why was it not a goal? It probably would have been a lot simpler, and it would
have worked with conventions besides Enumerable.{quote}
Ya I should add color to this. Given the discussions on the mailing list I
would like to add an optimization to our use case. Our Fact Tables contain a
single account hierarchy represented by a column {{sub_account}}. Often a Fact
will not be associated with an {{sub_account}} and so instead of storing that
as null and dealing with missing right hand row, we store a sentinel value in
the Fact so our joins to the account dimension are simpler. So when a query
comes in that for all Facts that do not contain a sub account, we want to
change the cost calculation of that filter as {{sub_account_sid == 'IS_NULL'}}
is not as selective as {{sub_account_sid = 'AC128485'}}. So my understanding
is, by translating into a {{RexDynamicParam}}, we lose out on this optimization.
> Hoist literals
> --
>
> Key: CALCITE-963
> URL: https://issues.apache.org/jira/browse/CALCITE-963
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Attachments: HoistedVariables.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Convert literals into (internal) bind variables so that statements that
> differ only in literal values can be executed using the same plan.
> In [mail
> thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201511.mbox/%3c56437bf8.70...@gmail.com%3E]
> Homer wrote:
> {quote}Imagine that it is common to run a large number of very similar
> machine generated queries that just change the literals in the sql query.
> For example (the real queries would be much more complex):
> {code}Select * from emp where empno = 1;
> Select * from emp where empno = 2;
> etc.{code}
> The plan that is likely being generated for these kind of queries is going to
> be very much the same each time, so to save some time, I would like to
> recognize that the literals are all that have changed in a query and use the
> previously optimized execution plan and just replace the literals.{quote}
> I think this could be done as a transform on the initial RelNode tree. It
> would find literals (RexLiteral), replace them with bind variables
> (RexDynamicParam) and write the value into a pool. The next statement would
> go through the same process and the RelNode tree would be identical, but with
> possibly different values for the bind variables.
> The bind variables are of course internal; not visible from JDBC. When the
> statement is executed, the bind variables are implicitly bound.
> Statements would be held in a Guava cache.
> This would be enabled by a config parameter. Unfortunately I don't think we
> could do this by default -- we'd lose optimization power because we would no
> longer be able to do constant reduction.
--
This message was
[jira] [Commented] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932829#comment-16932829
]
Scott Reynolds commented on CALCITE-963:
h1. Goal
When a query is issued to Calcite it is parsed, optimized and then generates a
String of Java Class that implements {{Bindable}}. {{EnumerableInterpretable}}
creates this string and checks to see if that string exists in
{{com.google.common.cache}} and if it doesn't it will call into a Java
compiler. Compilation process can take a considerable amount of time, Apache
Kylin reported 50 to 150ms of additional computation time. Today, Apache
Calcite will generate unique Java Class strings whenever any part of the query
changes. This document details out the design and implementation of a hoisting
technique within Apache Calcite. This design and implementation greatly
increases the cache hit rate of {{EnumerableInterpretable}}'s
{{BINDABLE_CACHE}}.
h1. Non Goals
This implementation is not designed to change the planning process. It does not
transform {{RexLiteral}} into {{RexDynamicParam}}, and doesn't change the cost
calculation of the query.
h1. Implementation Details
After a query has been optimized there are three phases that remaining phases
to the query:
# Generating the Java code
# Binding Hoisted Variables
# Runtime execution via {{Bindable.bind(DataContext, HoistedVariables)}}
Each of these phases will interact with a new class called {{HoistedVariables}}
[file:HoistedVariables.png|file:///HoistedVariables.png]
Each of these methods are used in the above three phases to hoist a variable
from within the query into the runtime execution of the {{Bindable}}.
The method {{implement}} of the interface {{EnumerableRel}} is used to generate
the Java code in phase one. Each of these {{RelNode}} can now call
{{registerVariable(String)}} to allocate a {{Slot}} for their unbound value.
This {{Slot}} is reserved for their use and is unique for the query plan. When
a {{RelNode}} registers a variable it needs to save that {{Slot}} into a
property so it can be referenced in phase 2. This {{Slot}} is then referenced
in code generation by calling {{EnumerableRel.lookupValue}} which returns an
{{Expression}} that will extract the bound value at for the {{Slot}}.
Below is a snippet from {{EnumerableLimit}} implementation of {{implement}}
that uses {{HoistedVariables}}.
{code:java}
Expression v = builder.append("child", result.block);
if (offset != null) {
if (offset instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) offset);
} else {
// Register with Hoisted Variable here
offsetIndex = variables.registerVariable("offset");
v = builder.append(
"offset",
Expressions.call(
v,
BuiltInMethod.SKIP.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(offsetIndex, Integer.class)));
}
}
if (fetch != null) {
if (fetch instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) fetch);
} else {
// Register with Hoisted Variable here
this.fetchIndex = variables.registerVariable("fetch");
v = builder.append(
"fetch",
Expressions.call(
v,
BuiltInMethod.TAKE.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(fetchIndex, Integer.class)));
}
}
{code}
The second phase of the query execution is where registered {{Slots}} get
bound. To this, our change adds a new optional method to {{Bindable}} called
{{hoistVariables}}. This method is where an instance of {{EnumerableRel}}
extracts the values out of the query plan and binds them into the
{{HoistedVariables}} instance just prior to executing the query. Below is
{{EnumerableLimit}} implementation:
{code:java}
@Override public void hoistedVariables(HoistedVariables variables) {
getInputs()
.stream()
.forEach(rel -> {
final EnumerableRel enumerable = (EnumerableRel) rel;
enumerable.hoistedVariables(variables);
});
if (fetchIndex != null) {
// fetchIndex is the registered slot for this variable. Bind fetchIndex to
fetch
variables.setVariable(fetchIndex, RexLiteral.intValue(fetch));
}
if (offsetIndex != null) {
// offsetIndex is the registered slot for this variable. Bind offsetIndex
to offset.
variables.setVariable(offsetIndex, RexLiteral.intValue(offset));
}
}
{code}
To tie these three phases together, {{CalcitePrepareImpl}} needs to setup the
variables when it creates a {{PreparedResult}}:
{code:java}
try {
CatalogReader.THREAD_LOCAL.set(catalogReader);
final SqlConformance conformance = context.config().conformance();
internalParameters.put("_conformance", conformance);
// Get the compiled Bindable instance either from cache or generate a new one.
bindable =
[jira] [Comment Edited] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932829#comment-16932829
]
Scott Reynolds edited comment on CALCITE-963 at 9/18/19 8:56 PM:
-
h1. Goal
When a query is issued to Calcite it is parsed, optimized and then generates a
String of Java Class that implements {{Bindable}}. {{EnumerableInterpretable}}
creates this string and checks to see if that string exists in
{{com.google.common.cache}} and if it doesn't it will call into a Java
compiler. Compilation process can take a considerable amount of time, Apache
Kylin reported 50 to 150ms of additional computation time. Today, Apache
Calcite will generate unique Java Class strings whenever any part of the query
changes. This document details out the design and implementation of a hoisting
technique within Apache Calcite. This design and implementation greatly
increases the cache hit rate of {{EnumerableInterpretable}}'s
{{BINDABLE_CACHE}}.
h1. Non Goals
This implementation is not designed to change the planning process. It does not
transform {{RexLiteral}} into {{RexDynamicParam}}, and doesn't change the cost
calculation of the query.
h1. Implementation Details
After a query has been optimized there are three phases that remaining phases
to the query:
# Generating the Java code
# Binding Hoisted Variables
# Runtime execution via {{Bindable.bind(DataContext, HoistedVariables)}}
Each of these phases will interact with a new class called {{HoistedVariables}}
Each of these methods are used in the above three phases to hoist a variable
from within the query into the runtime execution of the {{Bindable}}.
The method {{implement}} of the interface {{EnumerableRel}} is used to generate
the Java code in phase one. Each of these {{RelNode}} can now call
{{registerVariable(String)}} to allocate a {{Slot}} for their unbound value.
This {{Slot}} is reserved for their use and is unique for the query plan. When
a {{RelNode}} registers a variable it needs to save that {{Slot}} into a
property so it can be referenced in phase 2. This {{Slot}} is then referenced
in code generation by calling {{EnumerableRel.lookupValue}} which returns an
{{Expression}} that will extract the bound value at for the {{Slot}}.
Below is a snippet from {{EnumerableLimit}} implementation of {{implement}}
that uses {{HoistedVariables}}.
{code:java}
Expression v = builder.append("child", result.block);
if (offset != null) {
if (offset instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) offset);
} else {
// Register with Hoisted Variable here
offsetIndex = variables.registerVariable("offset");
v = builder.append(
"offset",
Expressions.call(
v,
BuiltInMethod.SKIP.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(offsetIndex, Integer.class)));
}
}
if (fetch != null) {
if (fetch instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) fetch);
} else {
// Register with Hoisted Variable here
this.fetchIndex = variables.registerVariable("fetch");
v = builder.append(
"fetch",
Expressions.call(
v,
BuiltInMethod.TAKE.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(fetchIndex, Integer.class)));
}
}
{code}
The second phase of the query execution is where registered {{Slots}} get
bound. To this, our change adds a new optional method to {{Bindable}} called
{{hoistVariables}}. This method is where an instance of {{EnumerableRel}}
extracts the values out of the query plan and binds them into the
{{HoistedVariables}} instance just prior to executing the query. Below is
{{EnumerableLimit}} implementation:
{code:java}
@Override public void hoistedVariables(HoistedVariables variables) {
getInputs()
.stream()
.forEach(rel -> {
final EnumerableRel enumerable = (EnumerableRel) rel;
enumerable.hoistedVariables(variables);
});
if (fetchIndex != null) {
// fetchIndex is the registered slot for this variable. Bind fetchIndex to
fetch
variables.setVariable(fetchIndex, RexLiteral.intValue(fetch));
}
if (offsetIndex != null) {
// offsetIndex is the registered slot for this variable. Bind offsetIndex
to offset.
variables.setVariable(offsetIndex, RexLiteral.intValue(offset));
}
}
{code}
To tie these three phases together, {{CalcitePrepareImpl}} needs to setup the
variables when it creates a {{PreparedResult}}:
{code:java}
try {
CatalogReader.THREAD_LOCAL.set(catalogReader);
final SqlConformance conformance = context.config().conformance();
internalParameters.put("_conformance", conformance);
// Get the compiled Bindable instance either from cache or generate a new one.
bindable =
[jira] [Comment Edited] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932829#comment-16932829
]
Scott Reynolds edited comment on CALCITE-963 at 9/18/19 9:09 PM:
-
h1. Goal
When a query is issued to Calcite it is parsed, optimized and then generates a
Java Class that implements {{Bindable}}. {{EnumerableInterpretable. }}This
class is then checked to see if it exists in {{com.google.common.cache}} and if
it doesn't it will call into a Java compiler. Compilation process can take a
considerable amount of time, Apache Kylin reported 50 to 150ms of additional
computation time. Today, Apache Calcite will generate unique Java Class strings
whenever any part of the query changes. This document details out the design
and implementation of a hoisting technique within Apache Calcite. This design
and implementation greatly increases the cache hit rate of
{{EnumerableInterpretable}}'s {{BINDABLE_CACHE}}.
h1. Non Goals
This implementation is not designed to change the planning process. It does not
transform {{RexLiteral}} into {{RexDynamicParam}}, and doesn't change the cost
calculation of the query.
h1. Implementation Details
After a query has been optimized there are three phases that remaining phases
to the query:
# Generating the Java code
# Binding Hoisted Variables
# Runtime execution via {{Bindable.bind(DataContext, HoistedVariables)}}
Each of these phases will interact with a new class called {{HoistedVariables}}
!HoistedVariables.png!
Each of these methods are used in the above three phases to hoist a variable
from within the query into the runtime execution of the {{Bindable}}.
The method {{implement}} of the interface {{EnumerableRel}} is used to generate
the Java code in phase one. Each of these {{RelNode}} can now call
{{registerVariable(String)}} to allocate a {{Slot}} for their unbound value.
This {{Slot}} is reserved for their use and is unique for the query plan. When
a {{RelNode}} registers a variable it needs to save that {{Slot}} into a
property so it can be referenced in phase 2. This {{Slot}} is then referenced
in code generation by calling {{EnumerableRel.lookupValue}} which returns an
{{Expression}} that will extract the bound value at for the {{Slot}}.
Below is a snippet from {{EnumerableLimit}} implementation of {{implement}}
that uses {{HoistedVariables}}.
{code:java}
Expression v = builder.append("child", result.block);
if (offset != null) {
if (offset instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) offset);
} else {
// Register with Hoisted Variable here
offsetIndex = variables.registerVariable("offset");
v = builder.append(
"offset",
Expressions.call(
v,
BuiltInMethod.SKIP.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(offsetIndex, Integer.class)));
}
}
if (fetch != null) {
if (fetch instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) fetch);
} else {
// Register with Hoisted Variable here
this.fetchIndex = variables.registerVariable("fetch");
v = builder.append(
"fetch",
Expressions.call(
v,
BuiltInMethod.TAKE.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(fetchIndex, Integer.class)));
}
}
{code}
The second phase of the query execution is where registered {{Slots}} get
bound. To this, our change adds a new optional method to {{Bindable}} called
{{hoistVariables}}. This method is where an instance of {{EnumerableRel}}
extracts the values out of the query plan and binds them into the
{{HoistedVariables}} instance just prior to executing the query. Below is
{{EnumerableLimit}} implementation:
{code:java}
@Override public void hoistedVariables(HoistedVariables variables) {
getInputs()
.stream()
.forEach(rel -> {
final EnumerableRel enumerable = (EnumerableRel) rel;
enumerable.hoistedVariables(variables);
});
if (fetchIndex != null) {
// fetchIndex is the registered slot for this variable. Bind fetchIndex to
fetch
variables.setVariable(fetchIndex, RexLiteral.intValue(fetch));
}
if (offsetIndex != null) {
// offsetIndex is the registered slot for this variable. Bind offsetIndex
to offset.
variables.setVariable(offsetIndex, RexLiteral.intValue(offset));
}
}
{code}
To tie these three phases together, {{CalcitePrepareImpl}} needs to setup the
variables when it creates a {{PreparedResult}}:
{code:java}
try {
CatalogReader.THREAD_LOCAL.set(catalogReader);
final SqlConformance conformance = context.config().conformance();
internalParameters.put("_conformance", conformance);
// Get the compiled Bindable instance either from cache or generate a new one.
bindable =
[jira] [Comment Edited] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932829#comment-16932829
]
Scott Reynolds edited comment on CALCITE-963 at 9/18/19 9:09 PM:
-
h1. Goal
When a query is issued to Calcite it is parsed, optimized and then generates a
Java Class that implements {{Bindable}}. {{EnumerableInterpretable. This class
is then checked to see if it exists in {{com.google.common.cache and if it
doesn't it will call into a Java compiler. Compilation process can take a
considerable amount of time, Apache Kylin reported 50 to 150ms of additional
computation time. Today, Apache Calcite will generate unique Java Class strings
whenever any part of the query changes. This document details out the design
and implementation of a hoisting technique within Apache Calcite. This design
and implementation greatly increases the cache hit rate of
{{EnumerableInterpretable}}'s {{BINDABLE_CACHE}}.
h1. Non Goals
This implementation is not designed to change the planning process. It does not
transform {{RexLiteral}} into {{RexDynamicParam}}, and doesn't change the cost
calculation of the query.
h1. Implementation Details
After a query has been optimized there are three phases that remaining phases
to the query:
# Generating the Java code
# Binding Hoisted Variables
# Runtime execution via {{Bindable.bind(DataContext, HoistedVariables)}}
Each of these phases will interact with a new class called {{HoistedVariables}}
!HoistedVariables.png!
Each of these methods are used in the above three phases to hoist a variable
from within the query into the runtime execution of the {{Bindable}}.
The method {{implement}} of the interface {{EnumerableRel}} is used to generate
the Java code in phase one. Each of these {{RelNode}} can now call
{{registerVariable(String)}} to allocate a {{Slot}} for their unbound value.
This {{Slot}} is reserved for their use and is unique for the query plan. When
a {{RelNode}} registers a variable it needs to save that {{Slot}} into a
property so it can be referenced in phase 2. This {{Slot}} is then referenced
in code generation by calling {{EnumerableRel.lookupValue}} which returns an
{{Expression}} that will extract the bound value at for the {{Slot}}.
Below is a snippet from {{EnumerableLimit}} implementation of {{implement}}
that uses {{HoistedVariables}}.
{code:java}
Expression v = builder.append("child", result.block);
if (offset != null) {
if (offset instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) offset);
} else {
// Register with Hoisted Variable here
offsetIndex = variables.registerVariable("offset");
v = builder.append(
"offset",
Expressions.call(
v,
BuiltInMethod.SKIP.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(offsetIndex, Integer.class)));
}
}
if (fetch != null) {
if (fetch instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) fetch);
} else {
// Register with Hoisted Variable here
this.fetchIndex = variables.registerVariable("fetch");
v = builder.append(
"fetch",
Expressions.call(
v,
BuiltInMethod.TAKE.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(fetchIndex, Integer.class)));
}
}
{code}
The second phase of the query execution is where registered {{Slots}} get
bound. To this, our change adds a new optional method to {{Bindable}} called
{{hoistVariables}}. This method is where an instance of {{EnumerableRel}}
extracts the values out of the query plan and binds them into the
{{HoistedVariables}} instance just prior to executing the query. Below is
{{EnumerableLimit}} implementation:
{code:java}
@Override public void hoistedVariables(HoistedVariables variables) {
getInputs()
.stream()
.forEach(rel -> {
final EnumerableRel enumerable = (EnumerableRel) rel;
enumerable.hoistedVariables(variables);
});
if (fetchIndex != null) {
// fetchIndex is the registered slot for this variable. Bind fetchIndex to
fetch
variables.setVariable(fetchIndex, RexLiteral.intValue(fetch));
}
if (offsetIndex != null) {
// offsetIndex is the registered slot for this variable. Bind offsetIndex
to offset.
variables.setVariable(offsetIndex, RexLiteral.intValue(offset));
}
}
{code}
To tie these three phases together, {{CalcitePrepareImpl}} needs to setup the
variables when it creates a {{PreparedResult}}:
{code:java}
try {
CatalogReader.THREAD_LOCAL.set(catalogReader);
final SqlConformance conformance = context.config().conformance();
internalParameters.put("_conformance", conformance);
// Get the compiled Bindable instance either from cache or generate a new one.
bindable =
[jira] [Comment Edited] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932829#comment-16932829
]
Scott Reynolds edited comment on CALCITE-963 at 9/18/19 9:14 PM:
-
h1. Goal
When a query is issued to Calcite it is parsed, optimized and then generates a
Java Class that implements {{Bindable}}. {{EnumerableInterpretable}}. This
class is then checked to see if it exists in {{com.google.common.cache}} and if
it doesn't it will call into a Java compiler. Compilation process can take a
considerable amount of time, Apache Kylin reported 50 to 150ms of additional
computation time. Today, Apache Calcite will generate unique Java Class strings
whenever any part of the query changes. This document details out the design
and implementation of a hoisting technique within Apache Calcite. This design
and implementation greatly increases the cache hit rate of
{{EnumerableInterpretable}}'s {{BINDABLE_CACHE}}.
h1. Non Goals
This implementation is not designed to change the planning process. It does not
transform {{RexLiteral}} into {{RexDynamicParam}}, and doesn't change the cost
calculation of the query.
h1. Implementation Details
After a query has been optimized there are three phases that remaining phases
to the query:
# Generating the Java code
# Binding Hoisted Variables
# Runtime execution via {{Bindable.bind(DataContext, HoistedVariables)}}
Each of these phases will interact with a new class called {{HoistedVariables}}
!HoistedVariables.png!
Each of these methods are used in the above three phases to hoist a variable
from within the query into the runtime execution of the {{Bindable}}.
The method {{implement}} of the interface {{EnumerableRel}} is used to generate
the Java code in phase one. Each of these {{RelNode}} can now call
{{registerVariable(String)}} to allocate a {{Slot}} for their unbound value.
This {{Slot}} is reserved for their use and is unique for the query plan. When
a {{RelNode}} registers a variable it needs to save that {{Slot}} into a
property so it can be referenced in phase 2. This {{Slot}} is then referenced
in code generation by calling {{EnumerableRel.lookupValue}} which returns an
{{Expression}} that will extract the bound value at for the {{Slot}}.
Below is a snippet from {{EnumerableLimit}} implementation of {{implement}}
that uses {{HoistedVariables}}.
{code:java}
Expression v = builder.append("child", result.block);
if (offset != null) {
if (offset instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) offset);
} else {
// Register with Hoisted Variable here
offsetIndex = variables.registerVariable("offset");
v = builder.append(
"offset",
Expressions.call(
v,
BuiltInMethod.SKIP.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(offsetIndex, Integer.class)));
}
}
if (fetch != null) {
if (fetch instanceof RexDynamicParam) {
v = getDynamicExpression((RexDynamicParam) fetch);
} else {
// Register with Hoisted Variable here
this.fetchIndex = variables.registerVariable("fetch");
v = builder.append(
"fetch",
Expressions.call(
v,
BuiltInMethod.TAKE.method,
// At runtime, fetch the bound variable. This returns the Java code to do
that.
EnumerableRel.lookupValue(fetchIndex, Integer.class)));
}
}
{code}
The second phase of the query execution is where registered {{Slots}} get
bound. To this, our change adds a new optional method to {{Bindable}} called
{{hoistVariables}}. This method is where an instance of {{EnumerableRel}}
extracts the values out of the query plan and binds them into the
{{HoistedVariables}} instance just prior to executing the query. Below is
{{EnumerableLimit}} implementation:
{code:java}
@Override public void hoistedVariables(HoistedVariables variables) {
getInputs()
.stream()
.forEach(rel -> {
final EnumerableRel enumerable = (EnumerableRel) rel;
enumerable.hoistedVariables(variables);
});
if (fetchIndex != null) {
// fetchIndex is the registered slot for this variable. Bind fetchIndex to
fetch
variables.setVariable(fetchIndex, RexLiteral.intValue(fetch));
}
if (offsetIndex != null) {
// offsetIndex is the registered slot for this variable. Bind offsetIndex
to offset.
variables.setVariable(offsetIndex, RexLiteral.intValue(offset));
}
}
{code}
To tie these three phases together, {{CalcitePrepareImpl}} needs to setup the
variables when it creates a {{PreparedResult}}:
{code:java}
try {
CatalogReader.THREAD_LOCAL.set(catalogReader);
final SqlConformance conformance = context.config().conformance();
internalParameters.put("_conformance", conformance);
// Get the compiled Bindable instance either from cache or generate a new one.
bindable =
[jira] [Created] (CALCITE-3361) Add a test that parses and validates a SQL statement with every built-in Redshift function
Julian Hyde created CALCITE-3361: Summary: Add a test that parses and validates a SQL statement with every built-in Redshift function Key: CALCITE-3361 URL: https://issues.apache.org/jira/browse/CALCITE-3361 Project: Calcite Issue Type: Bug Reporter: Julian Hyde Add a test that parses and validates a SQL statement with every built-in Redshift function. It would be part of the babel component, but would go beyond parsing, and also validate. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3349) Add Function DDL into SqlKind DDL enum
[
https://issues.apache.org/jira/browse/CALCITE-3349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932903#comment-16932903
]
Rong Rong commented on CALCITE-3349:
+1 on [~suez1224]'s point combining into one PR. also I think there's also
optimization we can do on the {{SqlExecutableStatement}} since there's a very
nice abstracton {{SqlDropObject}} on the drop side but not on the create side.
any reason why this particular approach is implemented?
> Add Function DDL into SqlKind DDL enum
> --
>
> Key: CALCITE-3349
> URL: https://issues.apache.org/jira/browse/CALCITE-3349
> Project: Calcite
> Issue Type: Improvement
> Components: core
>Reporter: Zhenqiu Huang
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, Create Function, Drop Function are not added into SqlKind DDL
> enum.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (CALCITE-963) Hoist literals
[
https://issues.apache.org/jira/browse/CALCITE-963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16932924#comment-16932924
]
Scott Reynolds commented on CALCITE-963:
Giving it some more thought, going to take another stab at this and just do the
{{RexDynamicParam}}. All of these changes and breakage is a good sign this
approach is fighting against the system. I will try another pass tomorrow.
> Hoist literals
> --
>
> Key: CALCITE-963
> URL: https://issues.apache.org/jira/browse/CALCITE-963
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
> Labels: pull-request-available
> Attachments: HoistedVariables.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Convert literals into (internal) bind variables so that statements that
> differ only in literal values can be executed using the same plan.
> In [mail
> thread|http://mail-archives.apache.org/mod_mbox/calcite-dev/201511.mbox/%3c56437bf8.70...@gmail.com%3E]
> Homer wrote:
> {quote}Imagine that it is common to run a large number of very similar
> machine generated queries that just change the literals in the sql query.
> For example (the real queries would be much more complex):
> {code}Select * from emp where empno = 1;
> Select * from emp where empno = 2;
> etc.{code}
> The plan that is likely being generated for these kind of queries is going to
> be very much the same each time, so to save some time, I would like to
> recognize that the literals are all that have changed in a query and use the
> previously optimized execution plan and just replace the literals.{quote}
> I think this could be done as a transform on the initial RelNode tree. It
> would find literals (RexLiteral), replace them with bind variables
> (RexDynamicParam) and write the value into a pool. The next statement would
> go through the same process and the RelNode tree would be identical, but with
> possibly different values for the bind variables.
> The bind variables are of course internal; not visible from JDBC. When the
> statement is executed, the bind variables are implicitly bound.
> Statements would be held in a Guava cache.
> This would be enabled by a config parameter. Unfortunately I don't think we
> could do this by default -- we'd lose optimization power because we would no
> longer be able to do constant reduction.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CALCITE-3346) Enable some ignored tests in RelOptRuleTests
[ https://issues.apache.org/jira/browse/CALCITE-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wang Yanlin updated CALCITE-3346: - Issue Type: Test (was: Improvement) > Enable some ignored tests in RelOptRuleTests > > > Key: CALCITE-3346 > URL: https://issues.apache.org/jira/browse/CALCITE-3346 > Project: Calcite > Issue Type: Test >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > When reading the code, i found that some ignored test case in > *RelOptRulesTest* actually can pass the test. Maybe we should try to enable > these tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3363) JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join
[ https://issues.apache.org/jira/browse/CALCITE-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16933072#comment-16933072 ] Wang Yanlin commented on CALCITE-3363: -- Can you give some more specific examples, I cannot see why it should not. > JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join > -- > > Key: CALCITE-3363 > URL: https://issues.apache.org/jira/browse/CALCITE-3363 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: jin xing >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > JoinUnionTransposeRule works by pull up union from below to top of join. Thus > it should not match semi/anti join by semantics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3355) Deduce whether CASE and COALESCE may produce NULL values
[ https://issues.apache.org/jira/browse/CALCITE-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16933046#comment-16933046 ] Danny Chan commented on CALCITE-3355: - Thanks [~kirillkozlov] for reporting this ~ > Deduce whether CASE and COALESCE may produce NULL values > > > Key: CALCITE-3355 > URL: https://issues.apache.org/jira/browse/CALCITE-3355 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.20.0 >Reporter: Kirill Kozlov >Priority: Major > > When executing queries like: > "SELECT COALESCE(name, 'unknown') as name_out FROM PCOLLECTION" > (input 'name' is nullable) > There is a need to know whether the result is nullable or not (in this case - > not). During validation stage "COALESCE" is being transformed (via > SqlValidatorImpl.performUnconditionalRewrites) into a "CASE" statement, which > currently does not determine nullability of a result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3363) JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join
jin xing created CALCITE-3363: - Summary: JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join Key: CALCITE-3363 URL: https://issues.apache.org/jira/browse/CALCITE-3363 Project: Calcite Issue Type: Bug Components: core Reporter: jin xing JoinUnionTransposeRule works by pull up union from below to top of join. Thus it should not match semi/anti join by semantics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3363) JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join
[ https://issues.apache.org/jira/browse/CALCITE-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3363: Labels: pull-request-available (was: ) > JoinUnionTransposeRule.RIGHT_UNION should not match SEMI/ANTI Join > -- > > Key: CALCITE-3363 > URL: https://issues.apache.org/jira/browse/CALCITE-3363 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: jin xing >Priority: Major > Labels: pull-request-available > > JoinUnionTransposeRule works by pull up union from below to top of join. Thus > it should not match semi/anti join by semantics. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3360) SqlValidator throws NEP for unregistered function without implicit type coercion
[ https://issues.apache.org/jira/browse/CALCITE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3360: Labels: pull-request-available (was: ) > SqlValidator throws NEP for unregistered function without implicit type > coercion > - > > Key: CALCITE-3360 > URL: https://issues.apache.org/jira/browse/CALCITE-3360 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.21.0 >Reporter: Danny Chan >Assignee: Danny Chan >Priority: Major > Labels: pull-request-available > Fix For: 1.22.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3362) Implementation for some empty tests of Lattice
Wang Yanlin created CALCITE-3362: Summary: Implementation for some empty tests of Lattice Key: CALCITE-3362 URL: https://issues.apache.org/jira/browse/CALCITE-3362 Project: Calcite Issue Type: Test Reporter: Wang Yanlin When read the code of lattice framework, came across some empty unit tests in [LatticeTest|https://github.com/apache/calcite/blob/67fd318ed755ef975cf31262c96c982f0922a975/core/src/test/java/org/apache/calcite/test/LatticeTest.java#L720]. Trying to implement these empty test cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3362) Implementation for some empty tests of Lattice
[ https://issues.apache.org/jira/browse/CALCITE-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3362: Labels: pull-request-available (was: ) > Implementation for some empty tests of Lattice > -- > > Key: CALCITE-3362 > URL: https://issues.apache.org/jira/browse/CALCITE-3362 > Project: Calcite > Issue Type: Test >Reporter: Wang Yanlin >Priority: Minor > Labels: pull-request-available > > When read the code of lattice framework, came across some empty unit tests in > [LatticeTest|https://github.com/apache/calcite/blob/67fd318ed755ef975cf31262c96c982f0922a975/core/src/test/java/org/apache/calcite/test/LatticeTest.java#L720]. > Trying to implement these empty test cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3355) Deduce whether CASE and COALESCE may produce NULL values
[ https://issues.apache.org/jira/browse/CALCITE-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16933010#comment-16933010 ] Chunwei Lei commented on CALCITE-3355: -- [~kirillkozlov] , I would like to task this issue if you don't mind. > Deduce whether CASE and COALESCE may produce NULL values > > > Key: CALCITE-3355 > URL: https://issues.apache.org/jira/browse/CALCITE-3355 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.20.0 >Reporter: Kirill Kozlov >Priority: Major > > When executing queries like: > "SELECT COALESCE(name, 'unknown') as name_out FROM PCOLLECTION" > (input 'name' is nullable) > There is a need to know whether the result is nullable or not (in this case - > not). During validation stage "COALESCE" is being transformed (via > SqlValidatorImpl.performUnconditionalRewrites) into a "CASE" statement, which > currently does not determine nullability of a result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (CALCITE-3355) Deduce whether CASE and COALESCE may produce NULL values
[ https://issues.apache.org/jira/browse/CALCITE-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16933010#comment-16933010 ] Chunwei Lei edited comment on CALCITE-3355 at 9/19/19 2:46 AM: --- [~kirillkozlov] , I would like to take this issue if you don't mind. was (Author: chunwei lei): [~kirillkozlov] , I would like to task this issue if you don't mind. > Deduce whether CASE and COALESCE may produce NULL values > > > Key: CALCITE-3355 > URL: https://issues.apache.org/jira/browse/CALCITE-3355 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.20.0 >Reporter: Kirill Kozlov >Priority: Major > > When executing queries like: > "SELECT COALESCE(name, 'unknown') as name_out FROM PCOLLECTION" > (input 'name' is nullable) > There is a need to know whether the result is nullable or not (in this case - > not). During validation stage "COALESCE" is being transformed (via > SqlValidatorImpl.performUnconditionalRewrites) into a "CASE" statement, which > currently does not determine nullability of a result. -- This message was sent by Atlassian Jira (v8.3.4#803005)
