You are viewing a plain text version of this content. The canonical link for it is here.
Posted to gitbox@hive.apache.org by GitBox <gi...@apache.org> on 2020/03/24 19:42:15 UTC

[GitHub] [hive] pgaref commented on issue #952: HIVE-23006 ProbeDecode compiler support

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:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: gitbox-unsubscribe@hive.apache.org
For additional commands, e-mail: gitbox-help@hive.apache.org