Venki Korukanti created DRILL-1928:
--------------------------------------
Summary: Refactor filter pushdown code
Key: DRILL-1928
URL: https://issues.apache.org/jira/browse/DRILL-1928
Project: Apache Drill
Issue Type: Improvement
Components: Query Planning & Optimization
Affects Versions: 0.7.0, 0.8.0
Reporter: Venki Korukanti
Assignee: Venki Korukanti
Fix For: Future
Currently in many places (InfoSchema, HBase, MongoDB and FS/Hive partition
pruning) we have logic to push the filter into scan.
1. We can have common code for visiting the expression tree and determining
which part of the tree can be pushed to scan and which part can't be pushed to
scan.
2. In all places, if we can't convert the complete filter, partially converted
filter is pushed into Scan but the complete filter is copied and evaluated in
Filter operator. This causes the partially pushed filter to be evaluated in two
places (Scan and Filter).
This JIRA proposes following API:
{code}
/**
* @param filter Filter expression tree
* @param fields List of columns names to consider when extracting the filter.
For example partition pruning is interested in only on expressions that involve
partition columns. In that case partition pruning can pass list of partition
columns as supported column list.
* @param functions List of supported functions to consider in extracting the
filter. For example partition pruning is interested in only "=", ">" etc. It
can pass these functions as the supported function list.
*
* @return Result contains two trees. One tree that can be pushed to Scan and
other tree that can't be pushed into Scan. Either of them can be null.
*/
FilterPruningResult extract(FilterExpression, FieldList, FunctionList)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
