[jira] [Commented] (IMPALA-988) Join strategy (broadcast vs shuffle) decision does not take mem limit and other joins into account
[ https://issues.apache.org/jira/browse/IMPALA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16795894#comment-16795894 ] ASF subversion and git services commented on IMPALA-988: Commit 6aacfd849a7fb07bc199e3fe3503eb5bcb0e410c in impala's branch refs/heads/branch-3.2.0 from Alex Rodoni [ https://gitbox.apache.org/repos/asf?p=impala.git;h=6aacfd8 ] IMPALA-8133: [DOCS] Review and update Known Issues for 3.2 - Added IMPALA-988 - Reviewed the Known Issues from 3.1 and updated the ones fixed in 3.2 Change-Id: Ia6b22fc5cf3944ffeeaf8189932e88498a14696e Reviewed-on: http://gerrit.cloudera.org:8080/12718 Tested-by: Impala Public Jenkins Reviewed-by: Paul Rogers > Join strategy (broadcast vs shuffle) decision does not take mem limit and > other joins into account > -- > > Key: IMPALA-988 > URL: https://issues.apache.org/jira/browse/IMPALA-988 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Affects Versions: Impala 1.2.1 >Reporter: Alan Choi >Priority: Minor > Labels: resource-management > > The amount of available memory changes the trade-off between partitioned and > shuffle join strategies: if switching to shuffle join can avoid spilling to > disk, it may be worth paying the cost of the additional network transfer. > There are two issues: > 1. Join strategy decision only takes query mem-limit into account but ignore > process mem-limit. > 2. Join strategy decision does not take other joins of the same query into > account. When multiple joins are present, it'll go over the mem-limit. > Note that when IMPALA-3200 is completed, this shouldn't prevent the query > running to completion, but still affects performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-988) Join strategy (broadcast vs shuffle) decision does not take mem limit and other joins into account
[ https://issues.apache.org/jira/browse/IMPALA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16793875#comment-16793875 ] ASF subversion and git services commented on IMPALA-988: Commit 4b83ff1a8d0cf97d45d01a89456f48a57031291d in impala's branch refs/heads/master from Alex Rodoni [ https://gitbox.apache.org/repos/asf?p=impala.git;h=4b83ff1 ] [DOCS] Removed IMPALA-988 from the Known Issues list Change-Id: I93e8ca3d0d070a75bb610f6f94c8bd78ddd5024f Reviewed-on: http://gerrit.cloudera.org:8080/12767 Reviewed-by: Alex Rodoni Tested-by: Impala Public Jenkins > Join strategy (broadcast vs shuffle) decision does not take mem limit and > other joins into account > -- > > Key: IMPALA-988 > URL: https://issues.apache.org/jira/browse/IMPALA-988 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Affects Versions: Impala 1.2.1 >Reporter: Alan Choi >Priority: Minor > Labels: resource-management > > The amount of available memory changes the trade-off between partitioned and > shuffle join strategies: if switching to shuffle join can avoid spilling to > disk, it may be worth paying the cost of the additional network transfer. > There are two issues: > 1. Join strategy decision only takes query mem-limit into account but ignore > process mem-limit. > 2. Join strategy decision does not take other joins of the same query into > account. When multiple joins are present, it'll go over the mem-limit. > Note that when IMPALA-3200 is completed, this shouldn't prevent the query > running to completion, but still affects performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-988) Join strategy (broadcast vs shuffle) decision does not take mem limit and other joins into account
[ https://issues.apache.org/jira/browse/IMPALA-988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16790102#comment-16790102 ] ASF subversion and git services commented on IMPALA-988: Commit 9cc75c59d5a09bd898bdf05cc64a98a70ffd in impala's branch refs/heads/master from Alex Rodoni [ https://gitbox.apache.org/repos/asf?p=impala.git;h=9cc75c5 ] IMPALA-8133: [DOCS] Review and update Known Issues for 3.2 - Added IMPALA-988 - Reviewed the Known Issues from 3.1 and updated the ones fixed in 3.2 Change-Id: Ia6b22fc5cf3944ffeeaf8189932e88498a14696e Reviewed-on: http://gerrit.cloudera.org:8080/12718 Tested-by: Impala Public Jenkins Reviewed-by: Paul Rogers > Join strategy (broadcast vs shuffle) decision does not take mem limit and > other joins into account > -- > > Key: IMPALA-988 > URL: https://issues.apache.org/jira/browse/IMPALA-988 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Affects Versions: Impala 1.2.1 >Reporter: Alan Choi >Priority: Minor > Labels: resource-management > > The amount of available memory changes the trade-off between partitioned and > shuffle join strategies: if switching to shuffle join can avoid spilling to > disk, it may be worth paying the cost of the additional network transfer. > There are two issues: > 1. Join strategy decision only takes query mem-limit into account but ignore > process mem-limit. > 2. Join strategy decision does not take other joins of the same query into > account. When multiple joins are present, it'll go over the mem-limit. > Note that when IMPALA-3200 is completed, this shouldn't prevent the query > running to completion, but still affects performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
