[
https://issues.apache.org/jira/browse/HIVE-23006?focusedWorklogId=409049&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-409049
]
ASF GitHub Bot logged work on HIVE-23006:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 24/Mar/20 19:42
Start Date: 24/Mar/20 19:42
Worklog Time Spent: 10m
Work Description: pgaref commented on issue #952: HIVE-23006 ProbeDecode
compiler support
URL: https://github.com/apache/hive/pull/952#issuecomment-603466661
> I started taking a look at your patch as well as code in master.
> I believe following approach would be easier since you could rely on
existing SJ logic.
> You could modify method `removeSemijoinsParallelToMapJoin` in
`TezCompiler`. In particular, `findParallelSemiJoinBranch` already finds all
semijoins originating in a MapJoin input (note that you may need small
modification in [this
block](https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/parse/TezCompiler.java#L1380)
to not skip adding them to the map). After calling that method, `semijoins`
will contain pairs (RS, TS). You will enter [this
block](https://github.com/apache/hive/blob/master/ql/src/java/org/apache/hadoop/hive/ql/parse/TezCompiler.java#L1486)
if `TEZ_DYNAMIC_SEMIJOIN_REDUCTION_FOR_MAPJOIN ` is `true` (note that you have
to remove this condition from L1450). Else, if
`HIVE_MAPJOIN_PROBEDECODE_ENABLED` is `true`, you will need to remove the SJs
(same as the block is doing) and create your optimization data structures,
i.e., your context in the TS as you are currently doing. You may end up with
multiple MJ targeting a single TS; you can generate a context for each of them,
store these in the TS, and decide later on a strategy to apply the filtering
based on a config parameter. Let me know if this makes sense.
>
> Cc @t3rmin4t0r
Hey @jcamachor , thanks for the comments!
I updated the patch to capture all (MJ, TS) pairs as part of
semijoinRemovalBasedTransformations
https://github.com/apache/hive/pull/952/files#diff-228178321e4c1df7f045fe181de2fffaR1453
I believe the TEZ_DYNAMIC_SEMIJOIN_REDUCTION_FOR_MAPJOIN flag should be
false for semijoin removal to kick in (if true the whole method returned in the
clean version)
https://github.com/apache/hive/pull/952/files#diff-228178321e4c1df7f045fe181de2fffaR1455
The idea of storing multiple MJ targets as part of a TS also makes sense to
me -- I guess the decision could be part of GenTezUtils or earlier optimisation
rules -- what do you think?
https://github.com/apache/hive/pull/952/files#diff-4a039ee6b13e42df6ff51e85db691132R199
PS: Was also thinking that the naming of this is a bit off
(HIVE_MAPJOIN_PROBEDECODE) -- as this can also be used for static expression.
----------------------------------------------------------------
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:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 409049)
Time Spent: 0.5h (was: 20m)
> Compiler support for Probe MapJoin
> ----------------------------------
>
> Key: HIVE-23006
> URL: https://issues.apache.org/jira/browse/HIVE-23006
> Project: Hive
> Issue Type: Sub-task
> Reporter: Panagiotis Garefalakis
> Assignee: Panagiotis Garefalakis
> Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The decision of pushing down information to the Record reader (potentially
> reducing decoding time by row-level filtering) should be done at query
> compilation time.
> This patch adds an extra optimisation step with the goal of finding Table
> Scan operators that could reduce the number of rows decoded at runtime using
> extra available information.
> It currently looks for all the available MapJoin operators that could use the
> smaller HashTable on the probing side (where TS is) to filter-out rows that
> would never match.
> To do so the HashTable information is pushed down to the TS properties and
> then propagated as part of MapWork.
> If the a single TS is used by multiple operators (shared-word), this rule can
> not be applied.
> This rule can be extended to support static filter expressions like:
> _select * from sales where sold_state = 'PR';_
> This optimisation manly targets the Tez execution engine running on Llap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
