[ https://issues.apache.org/jira/browse/HIVE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16599119#comment-16599119 ]
Vineet Garg commented on HIVE-18873: ------------------------------------ My understand is that Hive wants to apply whatever predicate it can to storage handler, but it also keep the predicate to itself (to apply it after storage handler on table scan operator) thus ensuring the correctness in case storage handler couldn't handle the predicates. I did more investigating and now I am not certain if this assumption is correct in all cases. Therefore I am taking back the patch. This will need further investigation. I still believe we should get in the current patch and investigate this in separate jira. > Skipping predicate pushdown for MR silently at HiveInputFormat can cause > storage handlers to produce erroneous result > --------------------------------------------------------------------------------------------------------------------- > > Key: HIVE-18873 > URL: https://issues.apache.org/jira/browse/HIVE-18873 > Project: Hive > Issue Type: Bug > Affects Versions: 3.0.0 > Reporter: Ankit Singhal > Assignee: Ankit Singhal > Priority: Major > Attachments: HIVE-18873.2.patch, HIVE-18873.2_reattach.patch, > HIVE-18873.patch > > > {code:java} > // disable filter pushdown for mapreduce when there are more than one table > aliases, > // since we don't clone jobConf per alias > if (mrwork != null && mrwork.getAliases() != null && > mrwork.getAliases().size() > 1 && > jobConf.get(ConfVars.HIVE_EXECUTION_ENGINE.varname).equals("mr")) { > return; > } > {code} > I believe this needs to be handled at OpProcFactory so that hive doesn't > believe that predicate is handled by storage handler. -- This message was sent by Atlassian JIRA (v7.6.3#76005)