[
https://issues.apache.org/jira/browse/FLINK-10474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647959#comment-16647959
]
ASF GitHub Bot commented on FLINK-10474:
----------------------------------------
fhueske commented on a change in pull request #6792: [FLINK-10474][table] Don't
translate IN/NOT_IN to JOIN with VALUES
URL: https://github.com/apache/flink/pull/6792#discussion_r224777959
##########
File path:
flink-libraries/flink-table/src/test/scala/org/apache/flink/table/runtime/batch/sql/CalcITCase.scala
##########
@@ -392,6 +392,47 @@ class CalcITCase(
val expected = List("a,a,d,d,e,e", "x,x,z,z,z,z").mkString("\n")
TestBaseUtils.compareResultAsText(results.asJava, expected)
}
+
+ @Test
+ def testIn(): Unit = {
+ val env = ExecutionEnvironment.getExecutionEnvironment
+ val tEnv = TableEnvironment.getTableEnvironment(env, config)
+
+ val sqlQuery = "SELECT * FROM MyTable WHERE b in (1,3,4,5,6)"
Review comment:
It would also be good to merge this with another test to keep the testing
overhead low.
Maybe change the predicate to `IN (2, 3, 4)` to keep the test more concise?
----------------------------------------------------------------
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
> Don't translate IN with Literals to JOIN with VALUES for streaming queries
> --------------------------------------------------------------------------
>
> Key: FLINK-10474
> URL: https://issues.apache.org/jira/browse/FLINK-10474
> Project: Flink
> Issue Type: Improvement
> Components: Table API & SQL
> Affects Versions: 1.6.1, 1.7.0
> Reporter: Fabian Hueske
> Assignee: Hequn Cheng
> Priority: Major
> Labels: pull-request-available
>
> IN predicates with literals are translated to JOIN with VALUES if the number
> of elements in the IN clause exceeds a certain threshold. This should not be
> done, because a streaming join is very heavy and materializes both inputs
> (which is fine for the VALUES) input but not for the other.
> There are two ways to solve this:
> # don't translate IN to a JOIN at all
> # translate it to a JOIN but have a special join strategy if one input is
> bound and final (non-updating)
> Option 1. should be easy to do, option 2. requires much more effort.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
