hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phabricator (JIRA)" <>
Subject [jira] [Commented] (HIVE-948) more query plan optimization rules
Date Sun, 10 Feb 2013 09:15:14 GMT


Phabricator commented on HIVE-948:

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

  Some comments.

  ql/src/java/org/apache/hadoop/hive/ql/optimizer/ I think better
name for this class could be NonBlockingOpDeDupProc ?
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/ It doesn't look
like terminal is used. This should be removed.
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/ Would also like
to add cFil = null here?
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/ looks like to be
safe we should also add cSel = null here.
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/ It will be good
to add comment why in case of sampling predicate we dont attempt to merge filters.
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/ Do you also want
to add : pSEL.getConf().setSelectStar (pSel.getConf().isSelectStar() || cSEL.getConf().isSelectStar);

  And similarly for selStarNoCompute ?
  ql/src/java/org/apache/hadoop/hive/ql/optimizer/ Do you also want
to add pFIL.getConf().setSortedFilter(pFIL.getConf().getSortedFilter() || cFIL.getConf().getSortedFilter());
  ql/src/java/org/apache/hadoop/hive/ql/ppd/ RS ->
MJ is disallowed after HIVE-3784, so this part of this rule can be removed.
  ql/src/java/org/apache/hadoop/hive/ql/ppd/ Add annotation




To: JIRA, ashutoshc, navis

> more query plan optimization rules 
> -----------------------------------
>                 Key: HIVE-948
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>            Reporter: Ning Zhang
>            Assignee: Navis
>         Attachments: HIVE-948.D8463.1.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:

View raw message