[
https://issues.apache.org/jira/browse/HIVE-11609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14743520#comment-14743520
]
Swarnim Kulkarni commented on HIVE-11609:
-----------------------------------------
{quote}
In one of .q tests, following line is removed :
filterExpr: ((key.col1 = '238') and (key.col2 = '1238')) (type: boolean)
which indicates filter was not pushed to TableScanOp.
{quote}
That not really true. With this issue I also found that it seems like the
pushdown predicates were getting handled twice, once by the storagehandler and
other by hive when they should only get handled by one of them(probably should
log another bug for that). So the tests were passing entirely because hive was
handling the predicates. The predicates were not even getting converted to the
hbase filter. After this fix, the test composite key factory implementation
passed to the query will start handling the predicates. That said, I am not
entirely sure at this point how that line actually got removed. I'll take a
look.
> Capability to add a filter to hbase scan via composite key doesn't work
> -----------------------------------------------------------------------
>
> Key: HIVE-11609
> URL: https://issues.apache.org/jira/browse/HIVE-11609
> Project: Hive
> Issue Type: Bug
> Components: HBase Handler
> Reporter: Swarnim Kulkarni
> Assignee: Swarnim Kulkarni
> Attachments: HIVE-11609.1.patch.txt, HIVE-11609.2.patch.txt
>
>
> It seems like the capability to add filter to an hbase scan which was added
> as part of HIVE-6411 doesn't work. This is primarily because in the
> HiveHBaseInputFormat, the filter is added in the getsplits instead of
> getrecordreader. This works fine for start and stop keys but not for filter
> because a filter is respected only when an actual scan is performed. This is
> also related to the initial refactoring that was done as part of HIVE-3420.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
