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] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
