[ 
https://issues.apache.org/jira/browse/HIVE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13577674#comment-13577674
 ] 

Phabricator commented on HIVE-948:
----------------------------------

ashutoshc has requested changes to the revision "HIVE-948 [jira] more query 
plan optimization rules".

  Mostly looks good. Have couple more comments. But I do think we need to name 
it better than CleanupProcessor.

INLINE COMMENTS
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/CleanupProcessor.java:47 
CleanupProcessor is not indicative of kind of optimization its doing. Its not 
descriptive enough. NonBlockingOpDeDupProc may not be an optimal choice. But we 
do need better than CleanupProcessor.
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/CleanupProcessor.java:83 What 
if parent isSelectStar and child is not? Shouldn't the surviving operator 
(parent) should be selectStar if either parent or child is.
  
ql/src/java/org/apache/hadoop/hive/ql/ppd/PredicateTransitivePropagate.java:75 
Per Namit's comment here: 
https://reviews.facebook.net/D5325?id=26877#inline-39651 RS->MJ is not allowed 
anymore. So, we should get rid of second predicate of this OR rule here.

REVISION DETAIL
  https://reviews.facebook.net/D8463

BRANCH
  DPAL-1980

ARCANIST PROJECT
  hive

To: JIRA, ashutoshc, navis

                
> more query plan optimization rules 
> -----------------------------------
>
>                 Key: HIVE-948
>                 URL: https://issues.apache.org/jira/browse/HIVE-948
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: Ning Zhang
>            Assignee: Navis
>         Attachments: HIVE-948.D8463.1.patch, HIVE-948.D8463.2.patch
>
>
> Many query plans are not optimal in that they contain redundant operators. 
> Some examples are unnecessary select operators (select followed by select, 
> select output being the same as input etc.). Even though these operators are 
> not very expensive, they could account for around 10% of CPU time in some 
> simple queries. It seems they are low-hanging fruits that we should pick 
> first. 
> BTW, it seems these optimization rules should be added at the last stage of 
> the physical optimization phase since some redundant operators are added to 
> facilitate physical plan generation. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to