Re: Question about Interpreter and Corelations

You may modify your sql and operator Collect should not reference correlate variables. XING JIN 于2019年11月9日周六 下午12:32写道： > Currently RelDecorrelator doesn't support a decorrelateRel(Collect), > that's why decorrelate failed > > Zoltan Farkas 于2019年11月9日周六 上午5:46写道： > >> Done:

Re: Re: Re: Optimizer: All the inputs have relevant nodes, however the cost is still infinite.

Xiening - You can reproduce it by running CoreQuidemTest in [1]. Haisheng - those enumerable rules all exist. My change in [1] shouldn't require implementing new enumerable rules. [1]: https://github.com/amaliujia/calcite/tree/rw-add_TVF_TUMBLE On Fri, Nov 8, 2019 at 12:04 PM Haisheng Yuan

Re: Question about Interpreter and Corelations

Currently RelDecorrelator doesn't support a decorrelateRel(Collect), that's why decorrelate failed Zoltan Farkas 于2019年11月9日周六 上午5:46写道： > Done: https://issues.apache.org/jira/browse/CALCITE-3488 < > https://issues.apache.org/jira/browse/CALCITE-3488> > let me know if you need any more info. >

Re: Question about Interpreter and Corelations

Done: https://issues.apache.org/jira/browse/CALCITE-3488 let me know if you need any more info. thank you —Z > On Nov 8, 2019, at 2:17 PM, Julian Hyde wrote: > > As I said, I think you should log a bug. > > On Fri, Nov 8, 2019 at 10:23

[jira] [Created] (CALCITE-3488) Interpreter does not implement LogicalCorelate.

Zoltan Farkas created CALCITE-3488: -- Summary: Interpreter does not implement LogicalCorelate. Key: CALCITE-3488 URL: https://issues.apache.org/jira/browse/CALCITE-3488 Project: Calcite

Re: Re: Re: Optimizer: All the inputs have relevant nodes, however the cost is still infinite.

Yes, looks like EnumerableTableFunctionScan doesn't override computeSelfCost. - Haisheng -- 发件人：Haisheng Yuan 日　期：2019年11月09日 04:01:19 收件人：Apache Calcite dev list 主　题：Re: Re: Optimizer: All the inputs have relevant nodes, however

Re: Re: Optimizer: All the inputs have relevant nodes, however the cost is still infinite.

It is not surprising to get an infinitive cost, since the operators in the plan are logical operators, which need to be converted to physical operators to be costed. Did you try to add some implementation rules to the rule set, e.g. EnumerableProjectRule, EnumerableTableFunctionScanRule, etc..

Re: Optimizer: All the inputs have relevant nodes, however the cost is still infinite.

Are you able to provide a test case to repro on current code base? From the error message, the given subset’s best RelNode is not available, aka cost is infinite. There could be multiple cases leading to it. > On Nov 8, 2019, at 11:28 AM, Rui Wang wrote: > > My current guess is it could

Re: Optimizer: All the inputs have relevant nodes, however the cost is still infinite.

My current guess is it could because of `computeSelfCost` of `EnumerableTableFunctionScan`. -Rui On Fri, Nov 8, 2019 at 10:04 AM Rui Wang wrote: > Hello community: > > I am stuck an optimizer error while working on Calcite-3272. I am less > familiar with Calcite's optimizer and struggled to

Re: Re: Question about Interpreter and Corelations

As I said, I think you should log a bug. On Fri, Nov 8, 2019 at 10:23 AM Haisheng Yuan wrote: > > I am afraid this query can't be easily decorrelated. > > - Haisheng > > -- > 发件人：Zoltan Farkas > 日　期：2019年11月08日 22:46:53 > 收件人： > 主　

Re: Re: Question about Interpreter and Corelations

I am afraid this query can't be easily decorrelated. - Haisheng -- 发件人：Zoltan Farkas 日　期：2019年11月08日 22:46:53 收件人： 主　题：Re: Question about Interpreter and Corelations Thanks Julian, Any idea how could I de-corelate the query?

Optimizer: All the inputs have relevant nodes, however the cost is still infinite.

Hello community: I am stuck an optimizer error while working on Calcite-3272. I am less familiar with Calcite's optimizer and struggled to debug the following error message. Is there some hints on what direction I should go? I can also provide more information if that is helpful. >

[jira] [Created] (CALCITE-3487) Should not hard code RelMetadataQuery class in VolcanoPlanner.isValid()

Xiening Dai created CALCITE-3487: Summary: Should not hard code RelMetadataQuery class in VolcanoPlanner.isValid() Key: CALCITE-3487 URL: https://issues.apache.org/jira/browse/CALCITE-3487 Project:

[jira] [Created] (CALCITE-3486) MysqlSqlDialect unparse ROW keyword does not exist

quxiucheng created CALCITE-3486: --- Summary: MysqlSqlDialect unparse ROW keyword does not exist Key: CALCITE-3486 URL: https://issues.apache.org/jira/browse/CALCITE-3486 Project: Calcite Issue

[jira] [Created] (CALCITE-3485) Validation error in UDF with overloads and dynamic parameter

Stamatis Zampetakis created CALCITE-3485: Summary: Validation error in UDF with overloads and dynamic parameter Key: CALCITE-3485 URL: https://issues.apache.org/jira/browse/CALCITE-3485

[jira] [Created] (CALCITE-3484) SqlToRelConverter: ClassCastException when processing a query with ANY and UNNEST

Ruben Q L created CALCITE-3484: -- Summary: SqlToRelConverter: ClassCastException when processing a query with ANY and UNNEST Key: CALCITE-3484 URL: https://issues.apache.org/jira/browse/CALCITE-3484

Re: Question about Interpreter and Corelations

Thanks Julian, Any idea how could I de-corelate the query? RelDecorrelator.decorrelateQuery does not seem to alter the plan. Will log a jira for the interpreter issue. thank you —Z > On Nov 7, 2019, at 5:08 PM, Julian Hyde wrote: > > I don’t recall what the interpreter is currently

Re: [DISCUSS] Proposal to add API to force rules matching specific rels

Hi Vladimir, I think the way PlannerTests#GoodSingleRule and EnumerableXXXRule work may help you ~ They work by a top-down fashion, but when matching parent, they convert the children explicitly. You may try below steps: 1. Construct a rule LogicalParentRule to match the LogicalParent without

Re: Re: [DISCUSS] On-demand traitset request

Hi Haisheng, Thanks a lot for sharing this great proposal ~ For short I understand your idea as below: 1. Derive the distributions/collations that children COULD/MIGHT offer 2. Decide the best distributions/collations by first point and computing logic of operator, say gropuings in Aggregate; It

Re: [avatica] STRUCT type information missing in type name

Hi Alessandro, >From what I understand ColumnMetaData mainly exists to provide the necessary information required to satisfy the API of ResultSetMetaData. As far as I can see the ResultSetMetaData does not provide the possibility to obtain information about nested struct fields (only top-level