[jira] [Resolved] (CALCITE-3931) Add LOOKAHEAD(2) for methods defined in createStatementParserMethods
[ https://issues.apache.org/jira/browse/CALCITE-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen resolved CALCITE-3931. - Resolution: Fixed Fixed in [5c2b158|https://github.com/apache/calcite/commit/5c2b15814b4fbe42a4f1d720ad99719c68c0448b] ! > Add LOOKAHEAD(2) for methods defined in createStatementParserMethods > > > Key: CALCITE-3931 > URL: https://issues.apache.org/jira/browse/CALCITE-3931 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.22.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.23.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The default LOOKAHEAD is 1 which is very probably to conflict, especially for > custom parse block like SqlCreate. > > Sets the LOOKAHEAD(2) to reduce conflict. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3931) Add LOOKAHEAD(2) for methods defined in createStatementParserMethods
[ https://issues.apache.org/jira/browse/CALCITE-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087412#comment-17087412 ] Danny Chen commented on CALCITE-3931: - It is hard to write a test case, i have tested and validated locally with my sql parser extension. {quote}it doesn't seem right that you have LOOKAHEAD only AFTER a '|' separator{quote} If we want to solve the conflicts between the multiple branches of just SqlCreate, LOOKAHEAD after '|' separator is enough. The first branch would have LOOKAHEAD(1) but it still works. > Add LOOKAHEAD(2) for methods defined in createStatementParserMethods > > > Key: CALCITE-3931 > URL: https://issues.apache.org/jira/browse/CALCITE-3931 > Project: Calcite > Issue Type: Improvement > Components: core >Affects Versions: 1.22.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Labels: pull-request-available > Fix For: 1.23.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The default LOOKAHEAD is 1 which is very probably to conflict, especially for > custom parse block like SqlCreate. > > Sets the LOOKAHEAD(2) to reduce conflict. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3940) Hint item can not parse correctly if the name is right after token "/*+"
[ https://issues.apache.org/jira/browse/CALCITE-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087377#comment-17087377 ] Chunwei Lei commented on CALCITE-3940: -- Hint item can not parse correctly -> Hint item can not be parsed correctly? > Hint item can not parse correctly if the name is right after token "/*+" > > > Key: CALCITE-3940 > URL: https://issues.apache.org/jira/browse/CALCITE-3940 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Fix For: 1.23.0 > > Time Spent: 10m > Remaining Estimate: 0h > > After parsing > {code:sql} > /*+OPTIONS('k1'='v1', 'k2'='v2')*/ > {code} > The parsed hint name is "PTIONS", while it is expected to be "OPTIONS". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3940) Hint item can not parse correctly if the name is right after token "/*+"
Danny Chen created CALCITE-3940: --- Summary: Hint item can not parse correctly if the name is right after token "/*+" Key: CALCITE-3940 URL: https://issues.apache.org/jira/browse/CALCITE-3940 Project: Calcite Issue Type: Bug Components: core Affects Versions: 1.22.0 Reporter: Danny Chen Assignee: Danny Chen Fix For: 1.23.0 After parsing /*+OPTIONS('k1'='v1', 'k2'='v2')*/, the parsed hint name is "PTIONS", while it is expected to be "OPTIONS". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3940) Hint item can not parse correctly if the name is right after token "/*+"
[ https://issues.apache.org/jira/browse/CALCITE-3940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Danny Chen updated CALCITE-3940: Description: After parsing {code:sql} /*+OPTIONS('k1'='v1', 'k2'='v2')*/ {code} The parsed hint name is "PTIONS", while it is expected to be "OPTIONS". was:After parsing /*+OPTIONS('k1'='v1', 'k2'='v2')*/, the parsed hint name is "PTIONS", while it is expected to be "OPTIONS". > Hint item can not parse correctly if the name is right after token "/*+" > > > Key: CALCITE-3940 > URL: https://issues.apache.org/jira/browse/CALCITE-3940 > Project: Calcite > Issue Type: Bug > Components: core >Affects Versions: 1.22.0 >Reporter: Danny Chen >Assignee: Danny Chen >Priority: Major > Fix For: 1.23.0 > > > After parsing > {code:sql} > /*+OPTIONS('k1'='v1', 'k2'='v2')*/ > {code} > The parsed hint name is "PTIONS", while it is expected to be "OPTIONS". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3938) Support LogicalCalc in RelShuttle
[ https://issues.apache.org/jira/browse/CALCITE-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087327#comment-17087327 ] Chunwei Lei commented on CALCITE-3938: -- Agree with [~jinxing6...@126.com]. > Support LogicalCalc in RelShuttle > - > > Key: CALCITE-3938 > URL: https://issues.apache.org/jira/browse/CALCITE-3938 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > visit LogicalCalc in RelShuttleImpl -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3938) Support LogicalCalc in RelShuttle
[ https://issues.apache.org/jira/browse/CALCITE-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chunwei Lei updated CALCITE-3938: - Summary: Support LogicalCalc in RelShuttle (was: implement visit LogicalCalc in RelShuttleImpl) > Support LogicalCalc in RelShuttle > - > > Key: CALCITE-3938 > URL: https://issues.apache.org/jira/browse/CALCITE-3938 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > visit LogicalCalc in RelShuttleImpl -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (CALCITE-3918) SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17
[ https://issues.apache.org/jira/browse/CALCITE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Haisheng Yuan resolved CALCITE-3918. Resolution: Not A Problem > SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17 > > > Key: CALCITE-3918 > URL: https://issues.apache.org/jira/browse/CALCITE-3918 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Disable RelDecorrelator and run TpchTest.testQuery17(), > SubQueryFilterRemoveRule generates plan with Correlate, which is not expected. > {code:java} > EnumerableProject(AVG_YEARLY=[/($0, 7.0:DECIMAL(2, 1))]) > EnumerableAggregate(group=[{}], agg#0=[SUM($2)]) > EnumerableFilter(condition=[AND(=($3, $0), =(CAST($4):VARCHAR, > 'Brand#13'), =(CAST($5):VARCHAR, 'JUMBO CAN'), <($1, $6))]) > EnumerableCorrelate(correlation=[$cor0], joinType=[left], > requiredColumns=[{3}]) > EnumerableNestedLoopJoin(condition=[true], joinType=[inner]) > EnumerableProject(L_PARTKEY=[$1], L_QUANTITY=[$4], > L_EXTENDEDPRICE=[$5]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > EnumerableProject(P_PARTKEY=[$0], P_BRAND=[$3], P_CONTAINER=[$6]) > EnumerableTableScan(table=[[TPCH_01, PART]]) > EnumerableProject($f0=[*(0.2:DECIMAL(2, 1), CAST(/(CASE(=($1, 0), > null:JavaType(class java.lang.Long), $0), $1)):JavaType(class > java.lang.Long))]) > EnumerableAggregate(group=[{}], agg#0=[$SUM0($4)], > agg#1=[COUNT($4)]) > EnumerableFilter(condition=[=($1, $cor0.P_PARTKEY)]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3918) SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17
[ https://issues.apache.org/jira/browse/CALCITE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087324#comment-17087324 ] Haisheng Yuan commented on CALCITE-3918: Sorry, my fault. Haven't read this piece of code for a long time. Will close this issue. > SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17 > > > Key: CALCITE-3918 > URL: https://issues.apache.org/jira/browse/CALCITE-3918 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Disable RelDecorrelator and run TpchTest.testQuery17(), > SubQueryFilterRemoveRule generates plan with Correlate, which is not expected. > {code:java} > EnumerableProject(AVG_YEARLY=[/($0, 7.0:DECIMAL(2, 1))]) > EnumerableAggregate(group=[{}], agg#0=[SUM($2)]) > EnumerableFilter(condition=[AND(=($3, $0), =(CAST($4):VARCHAR, > 'Brand#13'), =(CAST($5):VARCHAR, 'JUMBO CAN'), <($1, $6))]) > EnumerableCorrelate(correlation=[$cor0], joinType=[left], > requiredColumns=[{3}]) > EnumerableNestedLoopJoin(condition=[true], joinType=[inner]) > EnumerableProject(L_PARTKEY=[$1], L_QUANTITY=[$4], > L_EXTENDEDPRICE=[$5]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > EnumerableProject(P_PARTKEY=[$0], P_BRAND=[$3], P_CONTAINER=[$6]) > EnumerableTableScan(table=[[TPCH_01, PART]]) > EnumerableProject($f0=[*(0.2:DECIMAL(2, 1), CAST(/(CASE(=($1, 0), > null:JavaType(class java.lang.Long), $0), $1)):JavaType(class > java.lang.Long))]) > EnumerableAggregate(group=[{}], agg#0=[$SUM0($4)], > agg#1=[COUNT($4)]) > EnumerableFilter(condition=[=($1, $cor0.P_PARTKEY)]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized view matching
[ https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vineet Garg updated CALCITE-3928: - Labels: materializedviews (was: ) > Canonicalization doesn't do field trimming before materialized view matching > > > Key: CALCITE-3928 > URL: https://issues.apache.org/jira/browse/CALCITE-3928 > Project: Calcite > Issue Type: Bug >Reporter: Jin Xing >Priority: Major > Labels: materializedviews > > If we have query and materialized view as below: > {code:java} > query: > LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)]) > LogicalProject(a=$0, b=[bfunc($1)]) > LogicalTableScan(table=[[default, user_table]]) > mv: > LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)]) > LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)]) > LogicalTableScan(table=[[default, user_table]]) > {code} > The semantics of query and mv logic are the same. Materialized view matching > failed, because field trimming is not done when canonicalizing the plans. > Currently Calcite does field trimming when convert sql to rel. But my > company's internal system does materialization detection – – generates & > transforms & stores the RelNode. > Shall we add the field trimming when canonicalizing materialized view logic? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3928) Canonicalization doesn't do field trimming before materialized view matching
[ https://issues.apache.org/jira/browse/CALCITE-3928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087322#comment-17087322 ] Vineet Garg commented on CALCITE-3928: -- [~jinxing6...@126.com] Can you provide the actual query or test case? We might be missing a case for rewriting but I am not sure if I understand this fully. > Canonicalization doesn't do field trimming before materialized view matching > > > Key: CALCITE-3928 > URL: https://issues.apache.org/jira/browse/CALCITE-3928 > Project: Calcite > Issue Type: Bug >Reporter: Jin Xing >Priority: Major > > If we have query and materialized view as below: > {code:java} > query: > LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $1)]) > LogicalProject(a=$0, b=[bfunc($1)]) > LogicalTableScan(table=[[default, user_table]]) > mv: > LogicalAggregate(group=[{0}], EXPR$1=[afunc($1, $2)]) > LogicalProject(a=$0, b=[bfunc($1)], c=[bfunc($1)]) > LogicalTableScan(table=[[default, user_table]]) > {code} > The semantics of query and mv logic are the same. Materialized view matching > failed, because field trimming is not done when canonicalizing the plans. > Currently Calcite does field trimming when convert sql to rel. But my > company's internal system does materialization detection – – generates & > transforms & stores the RelNode. > Shall we add the field trimming when canonicalizing materialized view logic? > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3918) SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17
[ https://issues.apache.org/jira/browse/CALCITE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087319#comment-17087319 ] Vineet Garg commented on CALCITE-3918: -- SubQueryFilterRemoveRule can not decorrelate the plan. It basically removes subquery (RexSubQuery node) by rewriting queries into join and it may introduce Correlate expressions if there is any correlation in the query. RelDecorrelator is then suppose to be used to remove this correlation. > SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17 > > > Key: CALCITE-3918 > URL: https://issues.apache.org/jira/browse/CALCITE-3918 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Disable RelDecorrelator and run TpchTest.testQuery17(), > SubQueryFilterRemoveRule generates plan with Correlate, which is not expected. > {code:java} > EnumerableProject(AVG_YEARLY=[/($0, 7.0:DECIMAL(2, 1))]) > EnumerableAggregate(group=[{}], agg#0=[SUM($2)]) > EnumerableFilter(condition=[AND(=($3, $0), =(CAST($4):VARCHAR, > 'Brand#13'), =(CAST($5):VARCHAR, 'JUMBO CAN'), <($1, $6))]) > EnumerableCorrelate(correlation=[$cor0], joinType=[left], > requiredColumns=[{3}]) > EnumerableNestedLoopJoin(condition=[true], joinType=[inner]) > EnumerableProject(L_PARTKEY=[$1], L_QUANTITY=[$4], > L_EXTENDEDPRICE=[$5]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > EnumerableProject(P_PARTKEY=[$0], P_BRAND=[$3], P_CONTAINER=[$6]) > EnumerableTableScan(table=[[TPCH_01, PART]]) > EnumerableProject($f0=[*(0.2:DECIMAL(2, 1), CAST(/(CASE(=($1, 0), > null:JavaType(class java.lang.Long), $0), $1)):JavaType(class > java.lang.Long))]) > EnumerableAggregate(group=[{}], agg#0=[$SUM0($4)], > agg#1=[COUNT($4)]) > EnumerableFilter(condition=[=($1, $cor0.P_PARTKEY)]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3918) SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17
[ https://issues.apache.org/jira/browse/CALCITE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087318#comment-17087318 ] Haisheng Yuan commented on CALCITE-3918: I am expecting SubQueryFilterRemoveRule can decorrelate the plan. Am I getting it wrong? > SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17 > > > Key: CALCITE-3918 > URL: https://issues.apache.org/jira/browse/CALCITE-3918 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Disable RelDecorrelator and run TpchTest.testQuery17(), > SubQueryFilterRemoveRule generates plan with Correlate, which is not expected. > {code:java} > EnumerableProject(AVG_YEARLY=[/($0, 7.0:DECIMAL(2, 1))]) > EnumerableAggregate(group=[{}], agg#0=[SUM($2)]) > EnumerableFilter(condition=[AND(=($3, $0), =(CAST($4):VARCHAR, > 'Brand#13'), =(CAST($5):VARCHAR, 'JUMBO CAN'), <($1, $6))]) > EnumerableCorrelate(correlation=[$cor0], joinType=[left], > requiredColumns=[{3}]) > EnumerableNestedLoopJoin(condition=[true], joinType=[inner]) > EnumerableProject(L_PARTKEY=[$1], L_QUANTITY=[$4], > L_EXTENDEDPRICE=[$5]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > EnumerableProject(P_PARTKEY=[$0], P_BRAND=[$3], P_CONTAINER=[$6]) > EnumerableTableScan(table=[[TPCH_01, PART]]) > EnumerableProject($f0=[*(0.2:DECIMAL(2, 1), CAST(/(CASE(=($1, 0), > null:JavaType(class java.lang.Long), $0), $1)):JavaType(class > java.lang.Long))]) > EnumerableAggregate(group=[{}], agg#0=[$SUM0($4)], > agg#1=[COUNT($4)]) > EnumerableFilter(condition=[=($1, $cor0.P_PARTKEY)]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3918) SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17
[ https://issues.apache.org/jira/browse/CALCITE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087316#comment-17087316 ] Vineet Garg commented on CALCITE-3918: -- Thanks [~hyuan]. I am confused about this. If you disable RelDecorrelator how can you expect to remove Correlate expressions from the plan? What are the expectations here? > SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17 > > > Key: CALCITE-3918 > URL: https://issues.apache.org/jira/browse/CALCITE-3918 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Disable RelDecorrelator and run TpchTest.testQuery17(), > SubQueryFilterRemoveRule generates plan with Correlate, which is not expected. > {code:java} > EnumerableProject(AVG_YEARLY=[/($0, 7.0:DECIMAL(2, 1))]) > EnumerableAggregate(group=[{}], agg#0=[SUM($2)]) > EnumerableFilter(condition=[AND(=($3, $0), =(CAST($4):VARCHAR, > 'Brand#13'), =(CAST($5):VARCHAR, 'JUMBO CAN'), <($1, $6))]) > EnumerableCorrelate(correlation=[$cor0], joinType=[left], > requiredColumns=[{3}]) > EnumerableNestedLoopJoin(condition=[true], joinType=[inner]) > EnumerableProject(L_PARTKEY=[$1], L_QUANTITY=[$4], > L_EXTENDEDPRICE=[$5]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > EnumerableProject(P_PARTKEY=[$0], P_BRAND=[$3], P_CONTAINER=[$6]) > EnumerableTableScan(table=[[TPCH_01, PART]]) > EnumerableProject($f0=[*(0.2:DECIMAL(2, 1), CAST(/(CASE(=($1, 0), > null:JavaType(class java.lang.Long), $0), $1)):JavaType(class > java.lang.Long))]) > EnumerableAggregate(group=[{}], agg#0=[$SUM0($4)], > agg#1=[COUNT($4)]) > EnumerableFilter(condition=[=($1, $cor0.P_PARTKEY)]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3918) SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17
[ https://issues.apache.org/jira/browse/CALCITE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087315#comment-17087315 ] Haisheng Yuan commented on CALCITE-3918: Modify the code and return the relnode directly without decorrelating in RelDecorrelator. > SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17 > > > Key: CALCITE-3918 > URL: https://issues.apache.org/jira/browse/CALCITE-3918 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Disable RelDecorrelator and run TpchTest.testQuery17(), > SubQueryFilterRemoveRule generates plan with Correlate, which is not expected. > {code:java} > EnumerableProject(AVG_YEARLY=[/($0, 7.0:DECIMAL(2, 1))]) > EnumerableAggregate(group=[{}], agg#0=[SUM($2)]) > EnumerableFilter(condition=[AND(=($3, $0), =(CAST($4):VARCHAR, > 'Brand#13'), =(CAST($5):VARCHAR, 'JUMBO CAN'), <($1, $6))]) > EnumerableCorrelate(correlation=[$cor0], joinType=[left], > requiredColumns=[{3}]) > EnumerableNestedLoopJoin(condition=[true], joinType=[inner]) > EnumerableProject(L_PARTKEY=[$1], L_QUANTITY=[$4], > L_EXTENDEDPRICE=[$5]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > EnumerableProject(P_PARTKEY=[$0], P_BRAND=[$3], P_CONTAINER=[$6]) > EnumerableTableScan(table=[[TPCH_01, PART]]) > EnumerableProject($f0=[*(0.2:DECIMAL(2, 1), CAST(/(CASE(=($1, 0), > null:JavaType(class java.lang.Long), $0), $1)):JavaType(class > java.lang.Long))]) > EnumerableAggregate(group=[{}], agg#0=[$SUM0($4)], > agg#1=[COUNT($4)]) > EnumerableFilter(condition=[=($1, $cor0.P_PARTKEY)]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3918) SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17
[ https://issues.apache.org/jira/browse/CALCITE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17087313#comment-17087313 ] Vineet Garg commented on CALCITE-3918: -- [~hyuan] How do I disable the RelDecorrelator for this test? > SubQueryFilterRemoveRule failed to decorrelate subquery for TPCH q17 > > > Key: CALCITE-3918 > URL: https://issues.apache.org/jira/browse/CALCITE-3918 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: Haisheng Yuan >Priority: Major > > Disable RelDecorrelator and run TpchTest.testQuery17(), > SubQueryFilterRemoveRule generates plan with Correlate, which is not expected. > {code:java} > EnumerableProject(AVG_YEARLY=[/($0, 7.0:DECIMAL(2, 1))]) > EnumerableAggregate(group=[{}], agg#0=[SUM($2)]) > EnumerableFilter(condition=[AND(=($3, $0), =(CAST($4):VARCHAR, > 'Brand#13'), =(CAST($5):VARCHAR, 'JUMBO CAN'), <($1, $6))]) > EnumerableCorrelate(correlation=[$cor0], joinType=[left], > requiredColumns=[{3}]) > EnumerableNestedLoopJoin(condition=[true], joinType=[inner]) > EnumerableProject(L_PARTKEY=[$1], L_QUANTITY=[$4], > L_EXTENDEDPRICE=[$5]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > EnumerableProject(P_PARTKEY=[$0], P_BRAND=[$3], P_CONTAINER=[$6]) > EnumerableTableScan(table=[[TPCH_01, PART]]) > EnumerableProject($f0=[*(0.2:DECIMAL(2, 1), CAST(/(CASE(=($1, 0), > null:JavaType(class java.lang.Long), $0), $1)):JavaType(class > java.lang.Long))]) > EnumerableAggregate(group=[{}], agg#0=[$SUM0($4)], > agg#1=[COUNT($4)]) > EnumerableFilter(condition=[=($1, $cor0.P_PARTKEY)]) > EnumerableTableScan(table=[[TPCH_01, LINEITEM]]) > {code} -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3939) more auto pruning rules after SubstitutionRule is introduced
Botong Huang created CALCITE-3939: - Summary: more auto pruning rules after SubstitutionRule is introduced Key: CALCITE-3939 URL: https://issues.apache.org/jira/browse/CALCITE-3939 Project: Calcite Issue Type: Improvement Reporter: Botong Huang UnionEliminatorRule and ProjectRemoveRule are both pruning rules for a RelNode. They can also become SubstitutionRule with autoprune enabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (CALCITE-3938) implement visit LogicalCalc in RelShuttleImpl
[ https://issues.apache.org/jira/browse/CALCITE-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17086999#comment-17086999 ] Jin Xing commented on CALCITE-3938: --- How about rename the title as "Support LogicalCalc in RelShuttle" just as CALCITE-3607 ? > implement visit LogicalCalc in RelShuttleImpl > - > > Key: CALCITE-3938 > URL: https://issues.apache.org/jira/browse/CALCITE-3938 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > visit LogicalCalc in RelShuttleImpl -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CALCITE-3938) implement visit LogicalCalc in RelShuttleImpl
[ https://issues.apache.org/jira/browse/CALCITE-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CALCITE-3938: Labels: pull-request-available (was: ) > implement visit LogicalCalc in RelShuttleImpl > - > > Key: CALCITE-3938 > URL: https://issues.apache.org/jira/browse/CALCITE-3938 > Project: Calcite > Issue Type: Wish >Reporter: xzh_dz >Priority: Major > Labels: pull-request-available > > visit LogicalCalc in RelShuttleImpl -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (CALCITE-3938) implement visit LogicalCalc in RelShuttleImpl
xzh_dz created CALCITE-3938: --- Summary: implement visit LogicalCalc in RelShuttleImpl Key: CALCITE-3938 URL: https://issues.apache.org/jira/browse/CALCITE-3938 Project: Calcite Issue Type: Wish Reporter: xzh_dz visit LogicalCalc in RelShuttleImpl -- This message was sent by Atlassian Jira (v8.3.4#803005)