[
https://issues.apache.org/jira/browse/HIVE-24365?focusedWorklogId=511235&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-511235
]
ASF GitHub Bot logged work on HIVE-24365:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 13/Nov/20 06:51
Start Date: 13/Nov/20 06:51
Worklog Time Spent: 10m
Work Description: jcamachor commented on a change in pull request #1661:
URL: https://github.com/apache/hive/pull/1661#discussion_r522693729
##########
File path: ql/src/java/org/apache/hadoop/hive/ql/exec/Operator.java
##########
@@ -1543,4 +1544,11 @@ public final boolean logicalEqualsTree(Operator<?> o) {
}
return true;
}
+
+ public void replaceTabAlias(String oldAlias, String newAlias) {
Review comment:
I am wondering whether `replaceTabAlias` should be in the operator conf
(`OperatorDesc`). There is an `AbstractOperatorDesc` which could hold the
default logic. Then it could be exposed here by simply calling
`conf.replaceTabAlias` (single implementation for all operators).
The advantage that I see is that you would force any custom operator that
does not inherit `AbstractOperatorDesc` to implement this method (I know we do
not introduce such operators that much -or at all- but it seems to me it may
make sense from the separation of concepts perspective).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to 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
Issue Time Tracking
-------------------
Worklog Id: (was: 511235)
Time Spent: 20m (was: 10m)
> SWO should not create complex and redundant filter expressions
> --------------------------------------------------------------
>
> Key: HIVE-24365
> URL: https://issues.apache.org/jira/browse/HIVE-24365
> Project: Hive
> Issue Type: Improvement
> Reporter: Zoltan Haindrich
> Assignee: Zoltan Haindrich
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> for q88 we have complex and mostly unreadable filter expressions; because
> before merging 2 branches the TS filterexpression is pushed into a FIL
> operator.
> consider 3 scans with filters: (A,B,C)
> initially we have
> {code}
> T(A)
> T(B)
> T(C)
> {code}
> after merging A,B
> {code}
> T(A || B) -> FIL(A)
> -> FIL(B)
> T(C)
> {code}
> right now if we merge C as well:
> {code}
> T(A || B || C) -> FIL(A AND (A || B))
> -> FIL(B AND (A || B))
> -> FIL(C)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
