[
https://issues.apache.org/jira/browse/HIVE-23006?focusedWorklogId=417041&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-417041
]
ASF GitHub Bot logged work on HIVE-23006:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 06/Apr/20 19:07
Start Date: 06/Apr/20 19:07
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-609981295
> @pgaref , thanks for changes. Patch looks good. About the name, I think it
is fine (probe side for the filtering generated statically in case of
expressions or dynamically for joins).
>
> I think main remaining issue is related to selection in case of multiple
MJ operators. I was thinking that for the time being, we could make the policy
pluggable via config and have two very simple ones: 1) keep the one with lowest
`ndv_JOIN_probe_key_column / ndv_TS_target_column` ratio, or 2) keep those with
ratio below a certain threshold specified through a config value.
Alternatively, in this patch you could maybe go only with option 1 and tackle
other in follow-up.
>
> You have the information about the stats in the operators themselves
(follow `op.getStatistics()` calls to see how it is retrieved per column
basis). Thus, I would make that decision in the TezCompiler (once we gather all
the context information) rather than GenTezUtils.
@jcamachor thanks for the review, I appreciate it!
Please check the latest changes with:
- More generic probeDecode name for HiveConf
- TezCompiler with configurable logic to select a MJ when we have multiple
per TS -- currently picking the one with the lowest MJ/TS key Ratio
- SharedWork using a TS on multiple branches clears probeContext that would
result in wrong results
- probeContextDetails as part of the explained plan
- ProbeDecode Test cases with and without table stats
Thoughts?
My last concern is some operators like **VectorPTFEvaluatorDecimalAvg** that
do not allow the use of Selected (which is what probedecode is doing) and
whether we should take that into account as part of the optimizations.
----------------------------------------------------------------
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:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 417041)
Time Spent: 1.5h (was: 1h 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: 1.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)
