[
https://issues.apache.org/jira/browse/FLINK-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843097#comment-15843097
]
ASF GitHub Bot commented on FLINK-3849:
---------------------------------------
Github user twalthr commented on the issue:
https://github.com/apache/flink/pull/3166
I quickly went through the code. IMHO, we should limit the expressions
given to the FilterableTableSource to a minimum. E.g. if you look at the
[HCatInputFormat](https://hive.apache.org/javadocs/hcat-r0.5.0/inputoutput.html#Filter+Operators)
they only support very basic operations `'and', 'or', 'like', '()', '=', '<>'
(not equal), '<', '>', '<=' and '>='`. I think that is also enough for our use
case. We should also only support basic datatypes. Then we add a Filter after
the TableSource in case the TableSource does not support every predicate. What
do you think @fhueske?
The expression translation should also be more robust, just parsing the
Calcite string is very error-prone, can you construct the Expression using the
case-classes for that?
> Add FilterableTableSource interface and translation rule
> --------------------------------------------------------
>
> Key: FLINK-3849
> URL: https://issues.apache.org/jira/browse/FLINK-3849
> Project: Flink
> Issue Type: New Feature
> Components: Table API & SQL
> Reporter: Fabian Hueske
> Assignee: Anton Solovev
>
> Add a {{FilterableTableSource}} interface for {{TableSource}} implementations
> which support filter push-down.
> The interface could look as follows
> {code}
> def trait FilterableTableSource {
> // returns unsupported predicate expression
> def setPredicate(predicate: Expression): Expression
> }
> {code}
> In addition we need Calcite rules to push a predicate (or parts of it) into a
> TableScan that refers to a {{FilterableTableSource}}. We might need to tweak
> the cost model as well to push the optimizer in the right direction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
