[jira] [Commented] (CALCITE-1048) Make metadata more robust
[
https://issues.apache.org/jira/browse/CALCITE-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249131#comment-16249131
]
weijie.tong commented on CALCITE-1048:
--
[~julianhyde] Since
[CALCITE-794|https://issues.apache.org/jira/browse/CALCITE-794] has solved the
possible stack-overflow problems (If I don't misunderstand that jira.), I think
we could refactor the RelSubset's methods like this:
{code:java}
public Double getMaxRowCount(RelSubset rel, RelMetadataQuery mq) {
Double lowest = Double.POSITIVE_INFINITY;
for (RelNode node : rel.getRels()) {
Double maxRowCount = mq.getMaxRowCount(node);
if (maxRowCount == null) {
continue;
}
if (lowest.compareTo(maxRowCount) > 0) {
lowest = maxRowCount;
}
}
return lowest;
}
{code}
What do you think about this ?
> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Following CALCITE-794, make metadata more robust and performant, so we can
> safely derive metadata from a large RelNode graph.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2048) Create a better documentation for the Planner design
[ https://issues.apache.org/jira/browse/CALCITE-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16249028#comment-16249028 ] Edmon Begoli commented on CALCITE-2048: --- >From dev mailing list, from [~julianhyde]: 1. I would run planner tests (e.g. RelOptRulesTest, PlannerTest, VolcanoPlannerTest) in a debugger. I would turn on tracing and try to understand the output. Frameworks and Planner may be useful classes if you find it difficult to create the environment needed for a planner. 2. VolcanoPlanner.findBestExp() 3. I don’t know - it’s a complex piece of code 4. no - except for the parser 5. not much These are very quick answers. Others, please chime in with your answers. > Create a better documentation for the Planner design > > > Key: CALCITE-2048 > URL: https://issues.apache.org/jira/browse/CALCITE-2048 > Project: Calcite > Issue Type: Improvement > Components: core >Reporter: Edmon Begoli >Assignee: Edmon Begoli >Priority: Minor > Original Estimate: 672h > Remaining Estimate: 672h > > Per request of the development community, and the assessment that we need a > tutorial, documentation and example code to work directly with the planner, > because it is a lot harder to work with the planner than with an adapter. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-2039) AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..." and TableProjectableFilterable
[
https://issues.apache.org/jira/browse/CALCITE-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248916#comment-16248916
]
Alexey Roytman commented on CALCITE-2039:
-
Michael, that's right.
> AssertionError at Mappings.create(Mappings.java:64) with "select 0 as c1,..."
> and TableProjectableFilterable
>
>
> Key: CALCITE-2039
> URL: https://issues.apache.org/jira/browse/CALCITE-2039
> Project: Calcite
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.0
>Reporter: Alexey Roytman
>Assignee: Michael Mior
> Attachments: CALCITE-2039.zip, calcite_2039_eclipse_project.zip
>
>
> When I use a ProjectableFilterableTable interface, the following query
> (notice the "select 0 as c1, ...")
> {code}
> select 0 as c1, D101.c1 as c3, D101.c2 as c4, D101.c3 as c5 from (
> select T101.Category as c1, T101.Revenue as c2,
> T101."YEAR" as c3 from (
> select "YEAR", Category, "MONTH", Territory, Quarter, Sub_Category,
> Age_Group, Gender, Country, Revenue, Num_Of_Orders, "DATE" from
> XSchema.HDP) T101) D101
> {code}
> causes an exception:
> {noformat}
> java.lang.AssertionError
> at org.apache.calcite.util.mapping.Mappings.create(Mappings.java:64)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:277)
> at org.apache.calcite.rel.core.Project.getMapping(Project.java:257)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule.apply(ProjectTableScanRule.java:100)
> at
> org.apache.calcite.rel.rules.ProjectTableScanRule$3.onMatch(ProjectTableScanRule.java:83)
> at
> org.apache.calcite.plan.volcano.VolcanoRuleCall.onMatch(VolcanoRuleCall.java:212)
> at
> org.apache.calcite.plan.volcano.VolcanoPlanner.findBestExp(VolcanoPlanner.java:650)
> at org.apache.calcite.tools.Programs$5.run(Programs.java:326)
> at
> org.apache.calcite.tools.Programs$SequenceProgram.run(Programs.java:387)
> at org.apache.calcite.prepare.Prepare.optimize(Prepare.java:188)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:321)
> at org.apache.calcite.prepare.Prepare.prepareSql(Prepare.java:230)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare2_(CalcitePrepareImpl.java:786)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepare_(CalcitePrepareImpl.java:640)
> at
> org.apache.calcite.prepare.CalcitePrepareImpl.prepareSql(CalcitePrepareImpl.java:610)
> at
> org.apache.calcite.jdbc.CalciteConnectionImpl.parseQuery(CalciteConnectionImpl.java:221)
> at
> org.apache.calcite.jdbc.CalciteMetaImpl.prepareAndExecute(CalciteMetaImpl.java:603)
> at
> org.apache.calcite.avatica.AvaticaConnection.prepareAndExecuteInternal(AvaticaConnection.java:638)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:149)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeQuery(AvaticaStatement.java:218)
> ...
> {noformat}
> In the Mappings.create(), mappingType is INVERSE_SURJECTION, and "assert
> sourceCount >= targetCount" throws the exception, because sourceCount is 3,
> and targetCount is 4.
> At the frame above, in Project.getMapping(), "projects" are: {{\[0, $1, $2,
> $0\]}} (1st is RexLiteral, others are RexInputRef). At the frame above, in
> EnumerableProject.getMapping(), getInput().getRowType() has only 3 fields in
> the table.
> I have a reproduction case (in Java) but it's not within a Calcite standard.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-2042) Compatible types of columns combined via set operators may need explicit type-casting conversion
[
https://issues.apache.org/jira/browse/CALCITE-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16248809#comment-16248809
]
Julian Hyde commented on CALCITE-2042:
--
You are welcome to contribute a pull request for any open JIRA case. There are
some more details here: https://calcite.apache.org/develop/#getting-started
> Compatible types of columns combined via set operators may need explicit
> type-casting conversion
>
>
> Key: CALCITE-2042
> URL: https://issues.apache.org/jira/browse/CALCITE-2042
> Project: Calcite
> Issue Type: Bug
>Reporter: Liao Xintao
>Assignee: Julian Hyde
>Priority: Minor
>
> As knowns that columns combined via set operators (such as UNION, EXCEPT and
> INTERSECT) need not have exactly the same data type. So the SQL query is
> likely as below:
> {code:sql}
> select sum(bonus) from (
> (select sal as bonus from emp where empno < 100)
> UNION ALL
> (select sal * 0.5 as bonus from emp where empno >= 100)
> )
> {code}
> In this case, the data types of two "bonus" column are INTEGER and
> DECIMAL(12, 1) respectively, and the UNION operator derives DECIMAL(12, 1) as
> return type. The plan seems so good till I run it on Flink. The Flink
> UnionOperator validates the data types of two inputs and throws an exception
> because the two input types are not exactly the same.
> The underling systems based on calcite, like Flink, may adapt themselves to
> this kind of plan by modifying some codes. In my opinion, however, it may be
> a better way that the plan ensures the rules of data types of results of
> aggregation, (maybe) via rewriting the plan or adding explicit type-casting
> conversion which has been done when converting .
> Any feedback or advice is greatly appreciated.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
