[
https://issues.apache.org/jira/browse/IMPALA-14275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18013716#comment-18013716
]
ASF subversion and git services commented on IMPALA-14275:
----------------------------------------------------------
Commit 22898abbc44864775eff73c7ccedd893704baa27 in impala's branch
refs/heads/master from Joe McDonnell
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=22898abbc ]
IMPALA-14275: Ignore produced runtime filters for tuple cache keys
PlanNode's list of runtime filters includes both runtime filters
consumed and produced. The code for incorporating runtime filters
into the tuple cache key doesn't make a distinction between the
two. This means that JoinNodes that produce runtime filters hash
their children more than once. This only applies to mt_dop=0,
because mt_dop>0 produces the runtime filter from a separate build
side fragment. This hasn't produced a noticeable issue, but it is
still wrong. This ignores produced runtime filters.
Testing:
- Added a test case in TupleCacheTest
Change-Id: I5d132a5cf7de1ce19b55545171799d8f38bb8c3d
Reviewed-on: http://gerrit.cloudera.org:8080/23227
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Michael Smith <[email protected]>
> Tuple cache needs to differentiate between consumed vs produced runtime
> filters
> -------------------------------------------------------------------------------
>
> Key: IMPALA-14275
> URL: https://issues.apache.org/jira/browse/IMPALA-14275
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
> Affects Versions: Impala 5.0.0
> Reporter: Joe McDonnell
> Assignee: Joe McDonnell
> Priority: Major
> Fix For: Impala 5.0.0
>
>
> The tuple cache needs to include information about consumed runtime filters
> (e.g. a scan node receiving a runtime filter) to have a correct cache key.
> The code is currently considering all runtime filters whether they are
> produced or consumed. A hash join that produces a runtime filter will include
> that in the hash. We should only include this for consumed runtime filters.
> This only applies to mt_dop=0, because with mt_dop > 0 the runtime filter is
> produced by the join builder fragment, which doesn't enter into the
> calculations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]