[
https://issues.apache.org/jira/browse/FLINK-10638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674979#comment-16674979
]
ASF GitHub Bot commented on FLINK-10638:
----------------------------------------
pnowojski commented on a change in pull request #6981: [FLINK-10638][table]
Invalid table scan resolution for temporal join queries
URL: https://github.com/apache/flink/pull/6981#discussion_r230712519
##########
File path:
flink-libraries/flink-table/src/main/scala/org/apache/flink/table/plan/rules/FlinkRuleSets.scala
##########
@@ -39,18 +39,14 @@ object FlinkRuleSets {
SubQueryRemoveRule.JOIN)
/**
- * Handles proper conversion of correlate queries with temporal table
functions
- * into temporal table joins. This can create new table scans in the plan.
+ * Expand plan by replacing references to tables into a proper plan sub
trees. Those rules
+ * can create new plan nodes.
*/
- val TEMPORAL_JOIN_RULES: RuleSet = RuleSets.ofList(
- LogicalCorrelateToTemporalTableJoinRule.INSTANCE
- )
+ val EXPAND_PLAN_RULES: RuleSet = RuleSets.ofList(
Review comment:
It seems to me like providing just a configuration for those rules seems
like a halfmassure, since optimizer parameters are just as important as the
rules itself (like matching order (`BOTTOM_UP` or `TOP_DOWN`) or vulcano vs hep
sequential vs hep simultaneous.
Secondly I'm not sure why someone would want to play/change temporal rules
but not changing `TABLE_SUBQUERY_RULES` or `TABLE_REF_RULES`? And I see no
reason why someone would like to turn off/disable temporal join rules in the
first place - if you are not using temporal table function temporal rule will
not fire.
I think that we should either:
1. restrict configuration into just the simplest adding vulcano based rules
2. invest more time into a better configuration method of the rules, that
covers all of the possible use cases: matching order, vulcano vs hep, grouping
rules together, enforcing that some clean up rule is applied after a group of
other rules, etc etc.
3. tell the advance users that want to play with optimiser rules: just
override `opitmize()` method and/or create your custom `TableEnvironment`.
I would lean toward the combination of 1. and 3., thus I would drop this
issue of configuring `EXPAND_PLAN_RULES`
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Invalid table scan resolution for temporal join queries
> -------------------------------------------------------
>
> Key: FLINK-10638
> URL: https://issues.apache.org/jira/browse/FLINK-10638
> Project: Flink
> Issue Type: Bug
> Components: Table API & SQL
> Reporter: Timo Walther
> Assignee: Piotr Nowojski
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
>
> Registered tables that contain a temporal join are not properly resolved when
> performing a table scan.
> A planning error occurs when registering a table with a temporal join and
> reading from it again.
> {code}
> LogicalProject(amount=[*($0, $4)])
> LogicalFilter(condition=[=($3, $1)])
> LogicalCorrelate(correlation=[$cor0], joinType=[inner],
> requiredColumns=[{2}])
> LogicalTableScan(table=[[_DataStreamTable_0]])
>
> LogicalTableFunctionScan(invocation=[Rates(CAST($cor0.rowtime):TIMESTAMP(3)
> NOT NULL)], rowType=[RecordType(VARCHAR(65536) currency, BIGINT rate, TIME
> ATTRIBUTE(ROWTIME) rowtime)], elementType=[class [Ljava.lang.Object;])
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
