[jira] [Commented] (IMPALA-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621472#comment-16621472
]
Philip Zeyliger commented on IMPALA-7310:
-
I've not looked at how that test is hooked up, but it's entirely possible that
constant folding isn't happening in the test but would be happening in real
life for the constant expression.
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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] [Comment Edited] (IMPALA-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621434#comment-16621434
]
Paul Rogers edited comment on IMPALA-7310 at 9/20/18 3:02 AM:
--
Odd. Looked at the tests in {{ExprNdvTest}}. We have tests such as:
{noformat}
verifyNdv("case when id = 1 then 'yes' else 'no' end", 2);
{noformat}
This says that we convert the rand of values in column {{id}} into two values:
{{'yes'}} and {{'no'}}. So, the NDV of the expression is 2. Solid reasoning.
Then I added a new test using only constants:
{noformat}
verifyNdv("case when 0 = 1 then 'yes' else 'no' end", 2);
{noformat}
In this case, the NDV is reported as 2, when it should be 1 (the expression is
constant.)
Yes, this is a nit and few users will create such SQL. Still, I wonder if this
suggests other inconsistencies in NDV & selectivity handling?
Also, we seem to overuse "undefined":
{noformat}
verifyNdvTwoTable("case when id = 1 then date_string_col else tiny.b end",
-1);
{noformat}
This says that, depending on column {{id}} (which has stats), use either
{{date_string_col}} (which has stats) or {{tiny.b}} which does not. The result
is no NDV.
But, we know that the NDV is at least 736 (the value for {{date_string_col}}).
So, choosing -1 is throwing away data.
was (Author: paul.rogers):
Odd. Looked at the tests in {{ExprNdvTest}}. We have tests such as:
{noformat}
verifyNdv("case when id = 1 then 'yes' else 'no' end", 2);
{noformat}
This says that we convert the rand of values in column {{id}} into two values:
{{'yes'}} and {{'no'}}. So, the NDV of the expression is 2. Solid reasoning.
Then I added a new test using only constants:
{noformat}
verifyNdv("case when 0 = 1 then 'yes' else 'no' end", 2);
{noformat}
In this case, the NDV is reported as 2, when it should be 1 (the expression is
constant.)
Yes, this is a nit and few users will create such SQL. Still, I wonder if this
suggests other inconsistencies in NDV & selectivity handling?
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621434#comment-16621434
]
Paul Rogers commented on IMPALA-7310:
-
Odd. Looked at the tests in {{ExprNdvTest}}. We have tests such as:
{noformat}
verifyNdv("case when id = 1 then 'yes' else 'no' end", 2);
{noformat}
This says that we convert the rand of values in column {{id}} into two values:
{{'yes'}} and {{'no'}}. So, the NDV of the expression is 2. Solid reasoning.
Then I added a new test using only constants:
{noformat}
verifyNdv("case when 0 = 1 then 'yes' else 'no' end", 2);
{noformat}
In this case, the NDV is reported as 2, when it should be 1 (the expression is
constant.)
Yes, this is a nit and few users will create such SQL. Still, I wonder if this
suggests other inconsistencies in NDV & selectivity handling?
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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] [Comment Edited] (IMPALA-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621096#comment-16621096
]
Paul Rogers edited comment on IMPALA-7310 at 9/20/18 1:50 AM:
--
Simplest case: a binary predicate. Current behavior in
{{BinaryPredicate.analyzeImpl()}}:
{noformat}
long distinctValues = slotRefRef.getRef().getNumDistinctValues();
if (distinctValues > 0) {
selectivity_ = 1.0 / distinctValues;
selectivity_ = Math.max(0, Math.min(1, selectivity_));
}
{noformat}
So, if NDV is 0 (all nulls), selectivity is left at its default (-1, which
seems to mean "undefined".)
There are really two cases here:
1. We have stats. The 0 for NDV tells us that we either have 0 rows, or all
rows are null. In this case, we can safely assume that the NDV-with-nulls is 1.
2. We have no stats. NDV is unknown. But, we can use our default estimate in
{{Expr.DEFAULT_SELECTIVITY = 0.1}} to compute an a-priority NDV estimate of
1/selectivity = 10. (Or, more directly, use {{DEFAULT_SELECTIVITY}} as the
expression selectivity.)
To even consider such a change, we'd need to test the various paths. The only
test I could find for expressions and NDV are {{ExprNdvTest}} which tests with
and without stats, but not with an NDV=0 (as far as I can tell.)
Note that this test case uses a different definition for NDV than the
"distinct-non-null-values" definition used by the {{NDV\(x)}} function:
{noformat}
// When else not specified, it is NULL, verify it is counted
verifyNdv("case when id = 1 then 'yes' end", 2);
{noformat}
And, in {{Predicate.analyzeImpl()}}:
{noformat}
// values: true/false/null
numDistinctValues_ = 3;
{noformat}
was (Author: paul.rogers):
Simplest case: a binary predicate. Current behavior in
{{BinaryPredicate.analyzeImpl()}}:
{noformat}
long distinctValues = slotRefRef.getRef().getNumDistinctValues();
if (distinctValues > 0) {
selectivity_ = 1.0 / distinctValues;
selectivity_ = Math.max(0, Math.min(1, selectivity_));
}
{noformat}
So, if NDV is 0 (all nulls), selectivity is left at its default (-1, which
seems to mean "undefined".)
There are really two cases here:
1. We have stats. The 0 for NDV tells us that we either have 0 rows, or all
rows are null. In this case, we can safely assume that the NDV-with-nulls is 1.
2. We have no stats. NDV is unknown. But, we can use our default estimate in
{{Expr.DEFAULT_SELECTIVITY = 0.1}} to compute an a-priority NDV estimate of
1/selectivity = 10. (Or, more directly, use {{DEFAULT_SELECTIVITY}} as the
expression selectivity.)
To even consider such a change, we'd need to test the various paths. The only
test I could find for expressions and NDV are {{ExprNdvTest}} which tests with
and without stats, but not with an NDV=0 (as far as I can tell.)
Note that this test case uses a different definition for NDV than the
"distinct-non-null-values" definition used by the {{NDV\(x)}} function:
{noformat}
// When else not specified, it is NULL, verify it is counted
verifyNdv("case when id = 1 then 'yes' end", 2);
{noformat}
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
>
[jira] [Resolved] (IMPALA-7422) Crash in QueryState::PublishFilter() fragment_map_.count(params.dst_fragment_idx) == 1 (0 vs. 1)
[
https://issues.apache.org/jira/browse/IMPALA-7422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Ho resolved IMPALA-7422.
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Crash in QueryState::PublishFilter()
> fragment_map_.count(params.dst_fragment_idx) == 1 (0 vs. 1)
>
>
> Key: IMPALA-7422
> URL: https://issues.apache.org/jira/browse/IMPALA-7422
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Tim Armstrong
>Assignee: Michael Ho
>Priority: Blocker
> Labels: broken-build, crash
> Fix For: Impala 3.1.0
>
> Attachments:
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.ERROR.20180809-162257.28028.gz,
>
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.FATAL.20180809-201036.28028.gz,
>
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.INFO.20180809-162257.28028.gz,
>
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.WARNING.20180809-162257.28028.gz
>
>
> Ran into this running core tests on one of my patches.
> {noformat}
> query-state.cc:506] Check failed:
> fragment_map_.count(params.dst_fragment_idx) == 1 (0 vs. 1)
> *** Check failure stack trace: ***
> @ 0x4387b8c
> @ 0x4389431
> @ 0x4387566
> @ 0x438ab2d
> @ 0x1e0ba94
> @ 0x1f3d097
> @ 0x303fe61
> @ 0x303ddef
> @ 0x18fa28f
> @ 0x1d0d1b8
> @ 0x1d054b8
> @ 0x1d06bde
> @ 0x1d06a74
> @ 0x1d067c0
> @ 0x1d066d3
> @ 0x1c2d3c1
> @ 0x2041992
> @ 0x2049a6a
> @ 0x204998e
> @ 0x2049951
> @ 0x32b31d9
> @ 0x7fb7d61a2e24
> @ 0x7fb7d5ed034c
> {noformat}
> {noformat}
> 20:10:21 [gw0] PASSED
> query_test/test_runtime_filters.py::TestMinMaxFilters::test_min_max_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: kudu/none]
> 20:10:29
> query_test/test_runtime_filters.py::TestMinMaxFilters::test_large_strings
> 20:10:29 [gw0] PASSED
> query_test/test_runtime_filters.py::TestMinMaxFilters::test_large_strings
> 20:10:30
> query_test/test_runtime_filters.py::TestRuntimeRowFilters::test_row_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': True, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: parquet/none]
> 20:10:30 [gw3] PASSED
> query_test/test_runtime_filters.py::TestBloomFilters::test_bloom_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: seq/def/record]
> 20:10:32
> query_test/test_runtime_filters.py::TestBloomFilters::test_bloom_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': True, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: seq/def/record]
> 20:10:32 [gw4] PASSED
> query_test/test_queries.py::TestQueries::test_subquery[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': True,
> 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
> '100', 'batch_size': 0, 'num_nodes': 0} | table_format: rc/snap/block]
> 20:10:39 query_test/test_queries.py::TestQueries::test_subquery[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': False,
> 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
> '100', 'batch_size': 0, 'num_nodes': 0} | table_format: rc/snap/block]
> 20:10:39 [gw5] FAILED
> query_test/test_queries.py::TestQueries::test_analytic_fns[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': True,
> 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
> '100', 'batch_size': 0, 'num_nodes': 0} | table_format: text/bzip/block]
> 20:10:39
> query_test/test_queries.py::TestQueries::test_analytic_fns[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': False,
> 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
> '100', 'batch_size': 0, 'num_nodes': 0} | table_format: text/bzip/block]
> 20:10:39 [gw4]
[jira] [Commented] (IMPALA-7422) Crash in QueryState::PublishFilter() fragment_map_.count(params.dst_fragment_idx) == 1 (0 vs. 1)
[
https://issues.apache.org/jira/browse/IMPALA-7422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621379#comment-16621379
]
Michael Ho commented on IMPALA-7422:
[~tarmstrong], sorry for the late reply. Didn't see the last update till now.
There seems to be a second race which has yet to be addressed even though the
second race is very unlikely to occur. May be I should file a separate Jira for
that.
> Crash in QueryState::PublishFilter()
> fragment_map_.count(params.dst_fragment_idx) == 1 (0 vs. 1)
>
>
> Key: IMPALA-7422
> URL: https://issues.apache.org/jira/browse/IMPALA-7422
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Tim Armstrong
>Assignee: Michael Ho
>Priority: Blocker
> Labels: broken-build, crash
> Attachments:
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.ERROR.20180809-162257.28028.gz,
>
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.FATAL.20180809-201036.28028.gz,
>
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.INFO.20180809-162257.28028.gz,
>
> impalad.impala-ec2-centos74-m5-4xlarge-ondemand-17c2.vpc.cloudera.com.jenkins.log.WARNING.20180809-162257.28028.gz
>
>
> Ran into this running core tests on one of my patches.
> {noformat}
> query-state.cc:506] Check failed:
> fragment_map_.count(params.dst_fragment_idx) == 1 (0 vs. 1)
> *** Check failure stack trace: ***
> @ 0x4387b8c
> @ 0x4389431
> @ 0x4387566
> @ 0x438ab2d
> @ 0x1e0ba94
> @ 0x1f3d097
> @ 0x303fe61
> @ 0x303ddef
> @ 0x18fa28f
> @ 0x1d0d1b8
> @ 0x1d054b8
> @ 0x1d06bde
> @ 0x1d06a74
> @ 0x1d067c0
> @ 0x1d066d3
> @ 0x1c2d3c1
> @ 0x2041992
> @ 0x2049a6a
> @ 0x204998e
> @ 0x2049951
> @ 0x32b31d9
> @ 0x7fb7d61a2e24
> @ 0x7fb7d5ed034c
> {noformat}
> {noformat}
> 20:10:21 [gw0] PASSED
> query_test/test_runtime_filters.py::TestMinMaxFilters::test_min_max_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: kudu/none]
> 20:10:29
> query_test/test_runtime_filters.py::TestMinMaxFilters::test_large_strings
> 20:10:29 [gw0] PASSED
> query_test/test_runtime_filters.py::TestMinMaxFilters::test_large_strings
> 20:10:30
> query_test/test_runtime_filters.py::TestRuntimeRowFilters::test_row_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': True, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: parquet/none]
> 20:10:30 [gw3] PASSED
> query_test/test_runtime_filters.py::TestBloomFilters::test_bloom_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: seq/def/record]
> 20:10:32
> query_test/test_runtime_filters.py::TestBloomFilters::test_bloom_filters[exec_option:
> {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0,
> 'disable_codegen': True, 'abort_on_error': 1, 'debug_action': None,
> 'exec_single_node_rows_threshold': 0} | table_format: seq/def/record]
> 20:10:32 [gw4] PASSED
> query_test/test_queries.py::TestQueries::test_subquery[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': True,
> 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
> '100', 'batch_size': 0, 'num_nodes': 0} | table_format: rc/snap/block]
> 20:10:39 query_test/test_queries.py::TestQueries::test_subquery[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': False,
> 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
> '100', 'batch_size': 0, 'num_nodes': 0} | table_format: rc/snap/block]
> 20:10:39 [gw5] FAILED
> query_test/test_queries.py::TestQueries::test_analytic_fns[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': True,
> 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold':
> '100', 'batch_size': 0, 'num_nodes': 0} | table_format: text/bzip/block]
> 20:10:39
> query_test/test_queries.py::TestQueries::test_analytic_fns[exec_option:
> {'disable_codegen_rows_threshold': 0,
[jira] [Updated] (IMPALA-7597) "show partitions" does not retry on InconsistentMetadataFetchException
[
https://issues.apache.org/jira/browse/IMPALA-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v updated IMPALA-7597:
--
Description:
IMPALA-7530 added retries in case LocalCatalog throws
InconsistentMetadataFetchException. These retries apply to all code paths
taking {{Frontend#createExecRequest()}}.
"show partitions" additionally takes {{Frontend#getTableStats()} and aborts the
first time it sees InconsistentMetadataFetchException.
We need to make sure all the queries (especially DDLs) retry if they hit this
exception.
was:
IMPALA-7530 added retries in case LocalCatalog throws
InconsistentMetadataFetchException. These retries apply to all code paths
taking {{Frontend#createExecRequest()}}.
"show partitions" additionally {{Frontend#getTableStats()} and aborts the first
time it sees InconsistentMetadataFetchException.
We need to make sure all the queries (especially DDLs) retry if they hit this
exception.
> "show partitions" does not retry on InconsistentMetadataFetchException
> --
>
> Key: IMPALA-7597
> URL: https://issues.apache.org/jira/browse/IMPALA-7597
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 3.1.0
>Reporter: bharath v
>Assignee: Vuk Ercegovac
>Priority: Critical
>
> IMPALA-7530 added retries in case LocalCatalog throws
> InconsistentMetadataFetchException. These retries apply to all code paths
> taking {{Frontend#createExecRequest()}}.
> "show partitions" additionally takes {{Frontend#getTableStats()} and aborts
> the first time it sees InconsistentMetadataFetchException.
> We need to make sure all the queries (especially DDLs) retry if they hit this
> exception.
--
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] [Updated] (IMPALA-7597) "show partitions" does not retry on InconsistentMetadataFetchException
[
https://issues.apache.org/jira/browse/IMPALA-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
bharath v updated IMPALA-7597:
--
Description:
IMPALA-7530 added retries in case LocalCatalog throws
InconsistentMetadataFetchException. These retries apply to all code paths
taking {{Frontend#createExecRequest()}}.
"show partitions" additionally {{Frontend#getTableStats()} and aborts the first
time it sees InconsistentMetadataFetchException.
We need to make sure all the queries (especially DDLs) retry if they hit this
exception.
was:
IMPALA-7530 added retries in case LocalCatalog throws
InconsistentMetadataFetchException. These retries apply to all code paths
taking {{Frontend#createExecRequest()}}.
"show partitions" does not take this path and aborts the first time it sees
InconsistentMetadataFetchException. (It takes {{Frontend#getTableStats()}})
We need to make sure all the queries retry if they hit this exception.
> "show partitions" does not retry on InconsistentMetadataFetchException
> --
>
> Key: IMPALA-7597
> URL: https://issues.apache.org/jira/browse/IMPALA-7597
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 3.1.0
>Reporter: bharath v
>Assignee: Vuk Ercegovac
>Priority: Critical
>
> IMPALA-7530 added retries in case LocalCatalog throws
> InconsistentMetadataFetchException. These retries apply to all code paths
> taking {{Frontend#createExecRequest()}}.
> "show partitions" additionally {{Frontend#getTableStats()} and aborts the
> first time it sees InconsistentMetadataFetchException.
> We need to make sure all the queries (especially DDLs) retry if they hit this
> exception.
--
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] [Updated] (IMPALA-7599) Make num retries for InconsistentMetadataFetchException configurable
[ https://issues.apache.org/jira/browse/IMPALA-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath v updated IMPALA-7599: -- Issue Type: Improvement (was: Bug) > Make num retries for InconsistentMetadataFetchException configurable > > > Key: IMPALA-7599 > URL: https://issues.apache.org/jira/browse/IMPALA-7599 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Affects Versions: Impala 3.1.0 >Reporter: bharath v >Priority: Major > > Currently hardcoded to 10 (INCONSISTENT_METADATA_NUM_RETRIES) -- 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] [Updated] (IMPALA-7599) Make num retries for InconsistentMetadataFetchException configurable
[ https://issues.apache.org/jira/browse/IMPALA-7599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bharath v updated IMPALA-7599: -- Summary: Make num retries for InconsistentMetadataFetchException configurable (was: Make the retries for InconsistentMetadataFetchException configurable) > Make num retries for InconsistentMetadataFetchException configurable > > > Key: IMPALA-7599 > URL: https://issues.apache.org/jira/browse/IMPALA-7599 > Project: IMPALA > Issue Type: Bug > Components: Frontend >Affects Versions: Impala 3.1.0 >Reporter: bharath v >Priority: Major > > Currently hardcoded to 10 (INCONSISTENT_METADATA_NUM_RETRIES) -- 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-7597) "show partitions" does not retry on InconsistentMetadataFetchException
[
https://issues.apache.org/jira/browse/IMPALA-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621334#comment-16621334
]
bharath v commented on IMPALA-7597:
---
Adrian, I raised a separate jira for it, IMPALA-7599
> "show partitions" does not retry on InconsistentMetadataFetchException
> --
>
> Key: IMPALA-7597
> URL: https://issues.apache.org/jira/browse/IMPALA-7597
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 3.1.0
>Reporter: bharath v
>Assignee: Vuk Ercegovac
>Priority: Critical
>
> IMPALA-7530 added retries in case LocalCatalog throws
> InconsistentMetadataFetchException. These retries apply to all code paths
> taking {{Frontend#createExecRequest()}}.
> "show partitions" does not take this path and aborts the first time it sees
> InconsistentMetadataFetchException. (It takes {{Frontend#getTableStats()}})
> We need to make sure all the queries retry if they hit this exception.
--
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] [Created] (IMPALA-7599) Make the retries for InconsistentMetadataFetchException configurable
bharath v created IMPALA-7599: - Summary: Make the retries for InconsistentMetadataFetchException configurable Key: IMPALA-7599 URL: https://issues.apache.org/jira/browse/IMPALA-7599 Project: IMPALA Issue Type: Bug Components: Frontend Affects Versions: Impala 3.1.0 Reporter: bharath v Currently hardcoded to 10 (INCONSISTENT_METADATA_NUM_RETRIES) -- 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-7597) "show partitions" does not retry on InconsistentMetadataFetchException
[
https://issues.apache.org/jira/browse/IMPALA-7597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621330#comment-16621330
]
Adrian Ng commented on IMPALA-7597:
---
As part of this fix, we should make #retries configurable before throwing out
InconsistentMetadataFetchException. Even with 10, we are hitting this
exceptions with our workload.
> "show partitions" does not retry on InconsistentMetadataFetchException
> --
>
> Key: IMPALA-7597
> URL: https://issues.apache.org/jira/browse/IMPALA-7597
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 3.1.0
>Reporter: bharath v
>Assignee: Vuk Ercegovac
>Priority: Critical
>
> IMPALA-7530 added retries in case LocalCatalog throws
> InconsistentMetadataFetchException. These retries apply to all code paths
> taking {{Frontend#createExecRequest()}}.
> "show partitions" does not take this path and aborts the first time it sees
> InconsistentMetadataFetchException. (It takes {{Frontend#getTableStats()}})
> We need to make sure all the queries retry if they hit this exception.
--
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] [Created] (IMPALA-7598) Planner timeline not set in the runtime profile incase of errors
bharath v created IMPALA-7598:
-
Summary: Planner timeline not set in the runtime profile incase of
errors
Key: IMPALA-7598
URL: https://issues.apache.org/jira/browse/IMPALA-7598
Project: IMPALA
Issue Type: Bug
Components: Frontend
Affects Versions: Impala 3.1.0
Reporter: bharath v
Currently, the frontend sets the "Query compilation" timeline only if
doCreateExecRequest() finishes successfully.
{code}
private TExecRequest doCreateExecRequest(TQueryCtx queryCtx...) {
.. ..
timeline.markEvent("Planning finished");
result.setTimeline(timeline.toThrift());
return result;
}
{code}
There can be cases where the timeline could be useful for debugging when the
planning fails.
One recent case I came across is the exhaustion of retries on
InconsistentMetadataFetchException. For every retry of query due to this
exception, we add a timeline event.
{code}
while (true) {
try {
return doCreateExecRequest(queryCtx, timeline, explainString);
} catch (InconsistentMetadataFetchException e) {
if (attempt++ == INCONSISTENT_METADATA_NUM_RETRIES) {
throw e;
}
if (attempt > 1) {
// Back-off a bit on later retries.
Uninterruptibles.sleepUninterruptibly(200 * attempt,
TimeUnit.MILLISECONDS);
}
timeline.markEvent(
String.format("Retrying query planning due to inconsistent metadata
"
+ "fetch, attempt %s of %s: ",
attempt, INCONSISTENT_METADATA_NUM_RETRIES)
+ e.getMessage());
{code}
However, if the planning eventually fails, the timeline about retries is gone.
This would've confirmed that the query was re-tried for 10 times.
Would be really useful if we can populate the partial timeline, even if the
planning failed.
--
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] [Created] (IMPALA-7597) "show partitions" does not retry on InconsistentMetadataFetchException
bharath v created IMPALA-7597:
-
Summary: "show partitions" does not retry on
InconsistentMetadataFetchException
Key: IMPALA-7597
URL: https://issues.apache.org/jira/browse/IMPALA-7597
Project: IMPALA
Issue Type: Bug
Components: Frontend
Affects Versions: Impala 3.1.0
Reporter: bharath v
Assignee: Vuk Ercegovac
IMPALA-7530 added retries in case LocalCatalog throws
InconsistentMetadataFetchException. These retries apply to all code paths
taking {{Frontend#createExecRequest()}}.
"show partitions" does not take this path and aborts the first time it sees
InconsistentMetadataFetchException. (It takes {{Frontend#getTableStats()}})
We need to make sure all the queries retry if they hit this exception.
--
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] [Resolved] (IMPALA-7420) Alternative cancellation messages with "internal" cancellation
[ https://issues.apache.org/jira/browse/IMPALA-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Armstrong resolved IMPALA-7420. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 I added the infra to do this and converted some places. There are probably other opportunities to leverage this but it was non-trivial to figure out where the status would propagate to (we don't want to show an internal cancellation error if the cancellation was ultimately client initiated). I think it makes most sense to wait until the cancellation path is simplified, e.g. with IMPALA-2990 and then revisit. > Alternative cancellation messages with "internal" cancellation > -- > > Key: IMPALA-7420 > URL: https://issues.apache.org/jira/browse/IMPALA-7420 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 3.1.0 >Reporter: Tim Armstrong >Assignee: Tim Armstrong >Priority: Major > Fix For: Impala 3.1.0 > > > All CANCELLED statuses now have the same error message regardless of the > source of the cancellation. There are many places in the code where we > propagate "CANCELLED" statuses around the place internally, e.g. within > scans, for reasons unrelated to user-initiated cancellation. Those should not > leak > IMPALA-7418 was much harder to debug than necessary because it wasn't clear > where the CANCELLED status came from. -- 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-7420) Alternative cancellation messages with "internal" cancellation
[ https://issues.apache.org/jira/browse/IMPALA-7420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621274#comment-16621274 ] ASF subversion and git services commented on IMPALA-7420: - Commit 4845f98beecc90775f58e8e3eb72721e02252f18 in impala's branch refs/heads/master from [~tarmstr...@cloudera.com] [ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=4845f98 ] IMPALA-7420: different error code for internal cancellation I started by converting scan and spill-to-disk because the cancellation there is always meant to be internal to the scan and spill-to-disk subsystems. I updated all places that checked for TErrorCode::CANCELLED to treat CANCELLED_INTERNALLY the same. This is to aid triage and debugging of bugs like IMPALA-7418 where an "internal" cancellation leaks out into the query state. This will make it easier to determine if an internal cancellation somehow "leaked" out. Testing: Ran exhaustive tests. Change-Id: If25d5b539d68981359e4d881cae7b08728ba2999 Reviewed-on: http://gerrit.cloudera.org:8080/11464 Reviewed-by: Impala Public Jenkins Tested-by: Impala Public Jenkins > Alternative cancellation messages with "internal" cancellation > -- > > Key: IMPALA-7420 > URL: https://issues.apache.org/jira/browse/IMPALA-7420 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 3.1.0 >Reporter: Tim Armstrong >Assignee: Tim Armstrong >Priority: Major > > All CANCELLED statuses now have the same error message regardless of the > source of the cancellation. There are many places in the code where we > propagate "CANCELLED" statuses around the place internally, e.g. within > scans, for reasons unrelated to user-initiated cancellation. Those should not > leak > IMPALA-7418 was much harder to debug than necessary because it wasn't clear > where the CANCELLED status came from. -- 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-7488) TestShellCommandLine::test_cancellation hangs occasionally
[ https://issues.apache.org/jira/browse/IMPALA-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621271#comment-16621271 ] ASF subversion and git services commented on IMPALA-7488: - Commit 1d4a3f0e4f1f34e09759160981eca2d666ca58d3 in impala's branch refs/heads/master from [~twmarshall] [ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=1d4a3f0 ] IMPALA-7488: Fix hang in test_cancellation test_cancellation runs a impala-shell process with a query specified then sends a SIGINT and confirms that the shell cancels the query and exits. The hang was happening because the shell's signal handler was incorrectly using the same Thirft connection when calling Close() as the main shell thread, which is not thread safe. Testing: - Ran test_cancellation in a loop 500 times. Previously the hang would repro about every 10 runs. Change-Id: I9c4b570604f7706712eb8e19b1ce69bf35cf15e2 Reviewed-on: http://gerrit.cloudera.org:8080/11465 Reviewed-by: Impala Public Jenkins Reviewed-by: Tim Armstrong Tested-by: Impala Public Jenkins > TestShellCommandLine::test_cancellation hangs occasionally > -- > > Key: IMPALA-7488 > URL: https://issues.apache.org/jira/browse/IMPALA-7488 > Project: IMPALA > Issue Type: Bug > Components: Infrastructure >Affects Versions: Impala 3.1.0 >Reporter: Tim Armstrong >Assignee: Thomas Tauber-Marshall >Priority: Critical > Labels: broken-build > Attachments: psauxf.txt > > > We've seen a couple of hung builds with no queries running on the cluster. I > got "ps auxf" output and it looks like an impala-shell process is hanging > around. > I'm guessing the IMPALA-7407 fix somehow relates to this. -- 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-6568) The profile of all statements should contain the Query Compilation timeline
[
https://issues.apache.org/jira/browse/IMPALA-6568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621273#comment-16621273
]
ASF subversion and git services commented on IMPALA-6568:
-
Commit e4b349e15a47fc113f20233fed19d2a494f5878c in impala's branch
refs/heads/master from [~asherman]
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=e4b349e ]
IMPALA-7579: fix test_query_profile_contains_all_events on S3
This bug was introduced by IMPALA-6568 which added the
test_query_profile_contains_all_events test. This test creates a file
in the filesystem so that it can be used by 'load data inpath'. The
test was using the hdfs_client object to do file system operations, but
this client only works with hdfs. Switch to using the filesystem_client
object which can work on other filesystems, including s3. Also create
the file that will be moved by 'load data inpath' under the unique
database directory; this means the file can be created without having to
check if it exists already and must be deleted.
Change-Id: I7c6e0899455dd4e12636b959fab4bde79f02fb95
Reviewed-on: http://gerrit.cloudera.org:8080/11461
Reviewed-by: Impala Public Jenkins
Tested-by: Impala Public Jenkins
> The profile of all statements should contain the Query Compilation timeline
> ---
>
> Key: IMPALA-6568
> URL: https://issues.apache.org/jira/browse/IMPALA-6568
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
>Affects Versions: Impala 2.9.0, Impala 2.10.0, Impala 2.11.0
>Reporter: Alexander Behm
>Assignee: Andrew Sherman
>Priority: Major
> Labels: supportability
> Fix For: Impala 3.1.0
>
>
> Some statements do not seem to include the "Query Compilation" timeline in
> the query profile.
> Repro:
> {code}
> create table t (i int);
> describe t; <-- loads the table, but no FE timeline in profile
> invalidate metadata t;
> alter table t set tbproperties('numRows'='10'); <-- loads the table, but no
> FE timeline in profile
> {code}
> All statements should include the planner timeline.
--
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-7418) test_udf_errors - returns Cancelled instead of actual error
[
https://issues.apache.org/jira/browse/IMPALA-7418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621275#comment-16621275
]
ASF subversion and git services commented on IMPALA-7418:
-
Commit 4845f98beecc90775f58e8e3eb72721e02252f18 in impala's branch
refs/heads/master from [~tarmstr...@cloudera.com]
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=4845f98 ]
IMPALA-7420: different error code for internal cancellation
I started by converting scan and spill-to-disk because the
cancellation there is always meant to be internal to the scan and
spill-to-disk subsystems.
I updated all places that checked for TErrorCode::CANCELLED to treat
CANCELLED_INTERNALLY the same.
This is to aid triage and debugging of bugs like IMPALA-7418
where an "internal" cancellation leaks out into the query state.
This will make it easier to determine if an internal cancellation
somehow "leaked" out.
Testing:
Ran exhaustive tests.
Change-Id: If25d5b539d68981359e4d881cae7b08728ba2999
Reviewed-on: http://gerrit.cloudera.org:8080/11464
Reviewed-by: Impala Public Jenkins
Tested-by: Impala Public Jenkins
> test_udf_errors - returns Cancelled instead of actual error
> ---
>
> Key: IMPALA-7418
> URL: https://issues.apache.org/jira/browse/IMPALA-7418
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Tim Armstrong
>Assignee: Pooja Nilangekar
>Priority: Blocker
> Labels: broken-build
> Fix For: Impala 3.1.0
>
>
> {noformat}
> query_test.test_udfs.TestUdfExecution.test_udf_errors[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': True,
> 'exec_single_node_rows_threshold': 0, 'enable_expr_rewrites': True} |
> table_format: text/none] (from pytest)
> Failing for the past 1 build (Since Failed#2925 )
> Took 19 sec.
> add description
> Error Message
> query_test/test_udfs.py:415: in test_udf_errors
> self.run_test_case('QueryTest/udf-errors', vector, use_db=unique_database)
> common/impala_test_suite.py:412: in run_test_case
> self.__verify_exceptions(test_section['CATCH'], str(e), use_db)
> common/impala_test_suite.py:290: in __verify_exceptions (expected_str,
> actual_str) E AssertionError: Unexpected exception string. Expected:
> BadExpr2 prepare error E Not found in actual: ImpalaBeeswaxException: Query
> aborted:Cancelled
> Stacktrace
> query_test/test_udfs.py:415: in test_udf_errors
> self.run_test_case('QueryTest/udf-errors', vector, use_db=unique_database)
> common/impala_test_suite.py:412: in run_test_case
> self.__verify_exceptions(test_section['CATCH'], str(e), use_db)
> common/impala_test_suite.py:290: in __verify_exceptions
> (expected_str, actual_str)
> E AssertionError: Unexpected exception string. Expected: BadExpr2 prepare
> error
> E Not found in actual: ImpalaBeeswaxException: Query aborted:Cancelled
> Standard Error
> SET sync_ddl=False;
> -- executing against localhost:21000
> DROP DATABASE IF EXISTS `test_udf_errors_be4e0293` CASCADE;
> MainThread: Started query bd4790b45c20640d:9c62ffba
> SET sync_ddl=False;
> -- executing against localhost:21000
> CREATE DATABASE `test_udf_errors_be4e0293`;
> MainThread: Started query 474595a3ecba67bd:7a14c84
> MainThread: Created database "test_udf_errors_be4e0293" for test ID
> "query_test/test_udfs.py::TestUdfExecution::()::test_udf_errors[exec_option:
> {'disable_codegen_rows_threshold': 0, 'disable_codegen': True,
> 'exec_single_node_rows_threshold': 0, 'enable_expr_rewrites': True} |
> table_format: text/none]"
> -- executing against localhost:21000
> use test_udf_errors_be4e0293;
> MainThread: Started query 264b0cd09d289c09:cc5dafed
> SET disable_codegen_rows_threshold=0;
> SET disable_codegen=True;
> SET exec_single_node_rows_threshold=0;
> SET enable_expr_rewrites=True;
> -- executing against localhost:21000
> create function if not exists hive_pi() returns double
> location '/test-warehouse/hive-exec.jar'
> symbol='org.apache.hadoop.hive.ql.udf.UDFPI';
> MainThread: Started query ba41ccb6f020becd:db23209f
> -- executing against localhost:21000
> create function if not exists foo() returns double
> location '/test-warehouse/not-a-real-file.so'
> symbol='FnDoesNotExist';
> -- executing against localhost:21000
> create function if not exists foo() returns double
> location '/test-warehouse/not-a-real-file.so'
> symbol='FnDoesNotExist';
> -- executing against localhost:21000
> create function if not exists foo (string, string) returns string location
> '/test-warehouse/test_udf_errors_be4e0293_bad_udf.ll' symbol='MyAwesomeUdf';
> -- executing against localhost:21000
> create function if not exists twenty_args(int, int, int, int, int, int,
>
[jira] [Commented] (IMPALA-7579) TestObservability.test_query_profile_contains_all_events fails for S3 tests
[
https://issues.apache.org/jira/browse/IMPALA-7579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621272#comment-16621272
]
ASF subversion and git services commented on IMPALA-7579:
-
Commit e4b349e15a47fc113f20233fed19d2a494f5878c in impala's branch
refs/heads/master from [~asherman]
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=e4b349e ]
IMPALA-7579: fix test_query_profile_contains_all_events on S3
This bug was introduced by IMPALA-6568 which added the
test_query_profile_contains_all_events test. This test creates a file
in the filesystem so that it can be used by 'load data inpath'. The
test was using the hdfs_client object to do file system operations, but
this client only works with hdfs. Switch to using the filesystem_client
object which can work on other filesystems, including s3. Also create
the file that will be moved by 'load data inpath' under the unique
database directory; this means the file can be created without having to
check if it exists already and must be deleted.
Change-Id: I7c6e0899455dd4e12636b959fab4bde79f02fb95
Reviewed-on: http://gerrit.cloudera.org:8080/11461
Reviewed-by: Impala Public Jenkins
Tested-by: Impala Public Jenkins
> TestObservability.test_query_profile_contains_all_events fails for S3 tests
> ---
>
> Key: IMPALA-7579
> URL: https://issues.apache.org/jira/browse/IMPALA-7579
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 3.1.0
>Reporter: Vuk Ercegovac
>Assignee: Andrew Sherman
>Priority: Blocker
>
> For S3 tests, the test introduced in [https://gerrit.cloudera.org/#/c/11387/]
> fails with:
> {noformat}
> query_test/test_observability.py:225: in
> test_query_profile_contains_all_events
> self.hdfs_client.delete_file_dir(path)
> util/hdfs_util.py:90: in delete_file_dir
> if not self.exists(path):
> util/hdfs_util.py:138: in exists
> self.get_file_dir_status(path)
> util/hdfs_util.py:102: in get_file_dir_status
> return super(PyWebHdfsClientWithChmod, self).get_file_dir_status(path)
> /data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/infra/python/env/lib/python2.7/site-packages/pywebhdfs/webhdfs.py:335:
> in get_file_dir_status
> response = requests.get(uri, allow_redirects=True)
> /data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/infra/python/env/lib/python2.7/site-packages/requests/api.py:69:
> in get
> return request('get', url, params=params, **kwargs)
> /data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/infra/python/env/lib/python2.7/site-packages/requests/api.py:50:
> in request
> response = session.request(method=method, url=url, **kwargs)
> /data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/infra/python/env/lib/python2.7/site-packages/requests/sessions.py:465:
> in request
> resp = self.send(prep, **send_kwargs)
> /data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/infra/python/env/lib/python2.7/site-packages/requests/sessions.py:573:
> in send
> r = adapter.send(request, **kwargs)
> /data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/infra/python/env/lib/python2.7/site-packages/requests/adapters.py:415:
> in send
> raise ConnectionError(err, request=request)
> E ConnectionError: ('Connection aborted.', error(111, 'Connection
> refused')){noformat}
> The dir delete might want to be guarded by an "if exists". The failure cases
> may differ between hdfs and s3, which is probably what this test ran into.
--
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] [Created] (IMPALA-7596) Expose JvmPauseMonitor and GC Metrics to Impala's metrics infrastructure
Philip Zeyliger created IMPALA-7596: --- Summary: Expose JvmPauseMonitor and GC Metrics to Impala's metrics infrastructure Key: IMPALA-7596 URL: https://issues.apache.org/jira/browse/IMPALA-7596 Project: IMPALA Issue Type: Task Components: Infrastructure Reporter: Philip Zeyliger Assignee: Philip Zeyliger In IMPALA-6857 we added a thread that checks for GC pauses a bit. To allow monitoring tools to pick up on the fact that pauses are happening, it's useful to promote those as full-fledged metrics. It turns out we were also collecting those metrics by doing a lot of round trips to the Java side of the house. This JIRA may choose to address that as well. -- 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] [Created] (IMPALA-7595) Check failed: IsValidTime(time_) at timestamp-value.h:322
Tim Armstrong created IMPALA-7595:
-
Summary: Check failed: IsValidTime(time_) at timestamp-value.h:322
Key: IMPALA-7595
URL: https://issues.apache.org/jira/browse/IMPALA-7595
Project: IMPALA
Issue Type: Bug
Components: Backend
Affects Versions: Impala 3.1.0
Reporter: Tim Armstrong
Assignee: Csaba Ringhofer
See https://jenkins.impala.io/job/ubuntu-16.04-from-scratch/3197/. hash is
23c7d7e57b7868eedbf5a9a4bc4aafd6066a04fb
Some of the fuzz tests stand out amongst the tests that were running at the
same time as the crash, particularly:
19:12:17 [gw4] PASSED
query_test/test_scanners_fuzz.py::TestScannersFuzzing::test_fuzz_alltypes[exec_option:
{'debug_action': '-1:OPEN:SET_DENY_RESERVATION_PROBABILITY@1.0',
'abort_on_error': False, 'mem_limit': '512m', 'num_nodes': 0} | table_format:
parquet/none]
--
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] [Updated] (IMPALA-7582) Generate junit style symptoms for issues during cluster startup (minicluster and impala)
[
https://issues.apache.org/jira/browse/IMPALA-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nithya updated IMPALA-7582:
---
Summary: Generate junit style symptoms for issues during cluster startup
(minicluster and impala) (was: Generate symptoms for issues during cluster
startup (minicluster and impala))
> Generate junit style symptoms for issues during cluster startup (minicluster
> and impala)
>
>
> Key: IMPALA-7582
> URL: https://issues.apache.org/jira/browse/IMPALA-7582
> Project: IMPALA
> Issue Type: Task
> Components: Infrastructure
>Reporter: nithya
>Assignee: nithya
>Priority: Major
>
> Generate symptoms for steps in cluster startup (see testdata/bin/run-all.sh)
> As a sub-task for https://issues.apache.org/jira/browse/IMPALA-7399,
> run-all.sh script will be updated to generate junit type output that can be
> used to produce test reports. These reports can then be used to triage any
> failures/errors that happened during "Starting mini cluster" via run-all.sh
> script
>
> {noformat}
>
>
> name="generate_junitxml.Run_sentry_service.run_sentry" skipped="0" tests="1"
> time="0" timestamp="2018-09-17 18:06:34+00:00" url="None">
> name="run_sentry">
>
>
>
>
>
> {noformat}
--
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] [Updated] (IMPALA-7582) Generate symptoms for issues during cluster startup (minicluster and impala)
[
https://issues.apache.org/jira/browse/IMPALA-7582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nithya updated IMPALA-7582:
---
Description:
Generate symptoms for steps in cluster startup (see testdata/bin/run-all.sh)
As a sub-task for https://issues.apache.org/jira/browse/IMPALA-7399, run-all.sh
script will be updated to generate junit type output that can be used to
produce test reports. These reports can then be used to triage any
failures/errors that happened during "Starting mini cluster" via run-all.sh
script
{noformat}
{noformat}
was:Generate symptoms for steps in cluster startup (see
testdata/bin/run-all.sh)
> Generate symptoms for issues during cluster startup (minicluster and impala)
>
>
> Key: IMPALA-7582
> URL: https://issues.apache.org/jira/browse/IMPALA-7582
> Project: IMPALA
> Issue Type: Task
> Components: Infrastructure
>Reporter: nithya
>Assignee: nithya
>Priority: Major
>
> Generate symptoms for steps in cluster startup (see testdata/bin/run-all.sh)
> As a sub-task for https://issues.apache.org/jira/browse/IMPALA-7399,
> run-all.sh script will be updated to generate junit type output that can be
> used to produce test reports. These reports can then be used to triage any
> failures/errors that happened during "Starting mini cluster" via run-all.sh
> script
>
> {noformat}
>
>
> name="generate_junitxml.Run_sentry_service.run_sentry" skipped="0" tests="1"
> time="0" timestamp="2018-09-17 18:06:34+00:00" url="None">
> name="run_sentry">
>
>
>
>
>
> {noformat}
--
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-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621222#comment-16621222
]
Paul Rogers commented on IMPALA-7310:
-
[~jeszyb], agree completely. Here I'm digging down to do a root cause analysis.
Once we know what's what, we can figure out how to divide work up into tickets,
and which to do when. What I want to avoid is the whack-a-mole effect: solve
part of the problem which just causes another problem elsewhere.
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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] [Assigned] (IMPALA-7584) test_set fails when run against external cluster
[
https://issues.apache.org/jira/browse/IMPALA-7584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong reassigned IMPALA-7584:
-
Assignee: David Knupp (was: Tim Armstrong)
> test_set fails when run against external cluster
>
>
> Key: IMPALA-7584
> URL: https://issues.apache.org/jira/browse/IMPALA-7584
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Reporter: Tim Armstrong
>Assignee: David Knupp
>Priority: Major
>
> Similar to IMPALA-6810, test_set fails:
> {noformat}
> E AssertionError: Unexpected exception string. Expected: Rejected query
> from pool default-pool: minimum memory reservation
> E Not found in actual: ImpalaBeeswaxException: Query aborted:Rejected query
> from pool root.jenkins: minimum memory reservation is greater than memory
> available to the query for buffer reservations.
> {noformat}
--
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-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621196#comment-16621196
]
Paul Rogers commented on IMPALA-7310:
-
Here, it is worth pointing out the risk of any change. The current model
appears to not fit some use case (the one that triggered this ticket.) But, it
may well fit some real-world use cases. The risk of this (or any) change is
that we better fit the majority of use case, but we end up sub-optimizing for
the occasional use case that happens to fit the current model.
Next step is to do some testing to see the impact of any change on existing
tests. Anyone know of potential problems? Especially problems that led is to
the current implementation of how we handle missing NDV values?
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621171#comment-16621171
]
Paul Rogers commented on IMPALA-7310:
-
The original description pointed out the method that computes the compound NDV:
{noformat}
for (Expr expr: exprs) {
if (expr.getNumDistinctValues() == -1) {
numDistinctValues = -1;
break;
}
numDistinctValues *= expr.getNumDistinctValues();
}
{noformat}
This logic says, essentially, "if I don't know the actual NDV for any one group
of rows, then I don't know the NDV for the combination." This is literally
true. But, we ultimately need to make a decision: using some information is
better than using none.
Perhaps, when we don't know the NDV, we should assume one:
* If the NDV > 0, use it.
* If 0 and we have metadata, assume 1.
* If 0 and we have no metadata, assume 10 (see above.)
As suggested in a previous node, perhaps we can compute this number in each
node (because each node has the most information about the best a-priority
estimate for that expression/operator.) Then, we allow those a-priority
estimates to bubble up the tree with no special handling.
If we want, we could flag each node with a the source of the info (the three
cases above) to aid in debugging.
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621143#comment-16621143
]
Balazs Jeszenszky commented on IMPALA-7310:
---
[~Paul.Rogers] this one is about the fact that compute stats will come up with
a 0 NDV for an all-NULL column of non-zero cardinality. As a nice to have, we
could make cardinality estimation more robust against columns with 0 NDV, but
post this fix, that value would either be valid or manually set.
The rest sounds like valid improvement (it's probably that way because no one
made it better yet), but would need their own jiras.
FWIW, IMPALA-7528 is also somewhat related, if you want to fix these in one go.
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621126#comment-16621126
]
Paul Rogers commented on IMPALA-7310:
-
As noted above, the code uses -1 as an "undefined" selectivity marker. We saw
that, if NDV=0, we leave the value at "undefined". A quick read suggests we do
special handling further up the expression tree. See
{{PlanNode.coputeCombinedSelectify}}.
1. Remove conjuncts (expressions) with undefined selectivity.
2. If no expressions remain, add one with {{DEFAULT_SELECTIVITY}}.
This means that if we have no metadata, we treat the following identically:
{noformat}
WHERE x = 10
WHERE x = 10 AND y = 20 AND z = 30
{noformat}
Both are assumed to have a 0.1 selectivity, when one might argue that the
second should have 0.1^3 = 0.001 selectivity. (Actual code uses an exponential
back-off, ignored here.)
Note also the somewhat over-generalize use of {{DEFAULT_SELECTIVITY}}. If x =
10 has 0.1 selectivity, then does it make sense to assume that x < 10 has the
same? Some DB's assume a larger number (0.5, say) for inequalities. This
subtlety is lost in the 0.1 for everything approach.
Is this all this a bug or a feature?
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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-7498) impalad should wait for catalogd during start up
[ https://issues.apache.org/jira/browse/IMPALA-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621102#comment-16621102 ] bharath v commented on IMPALA-7498: --- Todd, I looked at the code and I don't think it will retry 3 times and then exit. It may be true in the earlier versions of V2 feature but I'm not able to track down the 3-time retry loop. Please correct me if I'm wrong. It waits indefinitely for the initial update but the issue happens to be with the log-spew. I've sent out of a patch here http://gerrit.cloudera.org:8080/11472 to fix it. > impalad should wait for catalogd during start up > > > Key: IMPALA-7498 > URL: https://issues.apache.org/jira/browse/IMPALA-7498 > Project: IMPALA > Issue Type: Sub-task >Reporter: Todd Lipcon >Assignee: bharath v >Priority: Major > > If you start all daemons simultaneously, impalad with --use_local_catalog > enabled will retry three times in a tight loop trying to fetch the DB names, > and then exit. Instead it should loop for some amount of time waiting for the > catalog to be ready in the same way that the existing implementation does. -- 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-7310) Compute Stats not computing NULLs as a distinct value causing wrong estimates
[
https://issues.apache.org/jira/browse/IMPALA-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16621096#comment-16621096
]
Paul Rogers commented on IMPALA-7310:
-
Simplest case: a binary predicate. Current behavior in
{{BinaryPredicate.analyzeImpl()}}:
{noformat}
long distinctValues = slotRefRef.getRef().getNumDistinctValues();
if (distinctValues > 0) {
selectivity_ = 1.0 / distinctValues;
selectivity_ = Math.max(0, Math.min(1, selectivity_));
}
{noformat}
So, if NDV is 0 (all nulls), selectivity is left at its default (-1, which
seems to mean "undefined".)
There are really two cases here:
1. We have stats. The 0 for NDV tells us that we either have 0 rows, or all
rows are null. In this case, we can safely assume that the NDV-with-nulls is 1.
2. We have no stats. NDV is unknown. But, we can use our default estimate in
{{Expr.DEFAULT_SELECTIVITY = 0.1}} to compute an a-priority NDV estimate of
1/selectivity = 10. (Or, more directly, use {{DEFAULT_SELECTIVITY}} as the
expression selectivity.)
To even consider such a change, we'd need to test the various paths. The only
test I could find for expressions and NDV are {{ExprNdvTest}} which tests with
and without stats, but not with an NDV=0 (as far as I can tell.)
Note that this test case uses a different definition for NDV than the
"distinct-non-null-values" definition used by the {{NDV\(x)}} function:
{noformat}
// When else not specified, it is NULL, verify it is counted
verifyNdv("case when id = 1 then 'yes' end", 2);
{noformat}
> Compute Stats not computing NULLs as a distinct value causing wrong estimates
> -
>
> Key: IMPALA-7310
> URL: https://issues.apache.org/jira/browse/IMPALA-7310
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.7.0, Impala 2.8.0, Impala 2.9.0, Impala 2.10.0,
> Impala 2.11.0, Impala 3.0, Impala 2.12.0
>Reporter: Zsombor Fedor
>Assignee: Paul Rogers
>Priority: Major
>
> As seen in other DBMSs
> {code:java}
> NDV(col){code}
> not counting NULL as a distinct value. The same also applies to
> {code:java}
> COUNT(DISTINCT col){code}
> This is working as intended, but when computing column statistics it can
> cause some anomalies (i.g. bad join order) as compute stats uses NDV() to
> determine columns NDVs.
>
> For example when aggregating more columns, the estimated cardinality is
> [counted as the product of the columns' number of distinct
> values.|https://github.com/cloudera/Impala/blob/64cd0bb0c3529efa0ab5452c4e9e2a04fd815b4f/fe/src/main/java/org/apache/impala/analysis/Expr.java#L669]
> If there is a column full of NULLs the whole product will be 0.
>
> There are two possible fix for this.
> Either we should count NULLs as a distinct value when Computing Stats in the
> query:
> {code:java}
> SELECT NDV(a) + COUNT(DISTINCT CASE WHEN a IS NULL THEN 1 END) AS a, CAST(-1
> as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
> instead of
> {code:java}
> SELECT NDV(a) AS a, CAST(-1 as BIGINT), 4, CAST(4 as DOUBLE) FROM test;{code}
>
>
> Or we should change the planner
> [function|https://github.com/cloudera/Impala/blob/2d2579cb31edda24457d33ff5176d79b7c0432c5/fe/src/main/java/org/apache/impala/planner/AggregationNode.java#L169]
> to take care of this bug.
>
--
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-7560) Better selectivity estimate for != (not equals) binary predicate
[
https://issues.apache.org/jira/browse/IMPALA-7560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620946#comment-16620946
]
Paul Rogers commented on IMPALA-7560:
-
The table in DRILL-5254 suggests how to use the NDV value to compute other
selectivity (reduction) factors such as for IN, <=, >= and so on.
It is hard to compute < and > without histograms. Even = and != are hard since,
if there are 5 NDVs, it is not clear if they are all 20% of the data, or one is
96% and the others are 1% each.
For example, consider HTTP status codes in a web log. There may be, say 10
distinct codes, but code 200 accounts for the vast majority of records (in a
healthy server.)
> Better selectivity estimate for != (not equals) binary predicate
>
>
> Key: IMPALA-7560
> URL: https://issues.apache.org/jira/browse/IMPALA-7560
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 2.8.0, Impala 2.9.0, Impala 2.10.0, Impala
> 2.12.0, Impala 2.13.0
>Reporter: bharath v
>Priority: Major
>
> Currently we use the default selectivity estimate for any binary predicate
> with op other than EQ / NON_DISTINCT.
> {noformat}
> // Determine selectivity
> // TODO: Compute selectivity for nested predicates.
> // TODO: Improve estimation using histograms.
> Reference slotRefRef = new Reference();
> if ((op_ == Operator.EQ || op_ == Operator.NOT_DISTINCT)
> && isSingleColumnPredicate(slotRefRef, null)) {
> long distinctValues = slotRefRef.getRef().getNumDistinctValues();
> if (distinctValues > 0) {
> selectivity_ = 1.0 / distinctValues;
> selectivity_ = Math.max(0, Math.min(1, selectivity_));
> }
> }
> {noformat}
> This can give very conservative estimates. For example:
> {noformat}
> [localhost:21000] tpch> select * from nation where n_regionkey != 1;
> [localhost:21000] tpch> summary;
> +--++--+--+---++---+---+-+
> | Operator | #Hosts | Avg Time | Max Time | *#Rows* | *Est. #Rows* | Peak
> Mem | Est. Peak Mem | Detail |
> +--++--+--+---++---+---+-+
> | 00:SCAN HDFS | 1 | 3.32ms | 3.32ms | *20*| *3* |
> 143.00 KB | 16.00 MB | tpch.nation |
> +--++--+--+---++---+---+-+
> [localhost:21000] tpch>
> {noformat}
> Ideally we could've inversed the selecitivity to 4/5 (=1 - 1/5) that can
> give better estimate.
--
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] [Work started] (IMPALA-7306) Add regression test for IMPALA-7305
[ https://issues.apache.org/jira/browse/IMPALA-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-7306 started by Tim Armstrong. - > Add regression test for IMPALA-7305 > --- > > Key: IMPALA-7306 > URL: https://issues.apache.org/jira/browse/IMPALA-7306 > Project: IMPALA > Issue Type: Bug > Components: Distributed Exec >Reporter: Tim Armstrong >Assignee: Tim Armstrong >Priority: Critical > Labels: statestore > > IMPALA-7305 got fixed as part of another change, but we should make sure that > we add a regression test. I think this should be possible if the subscriber > blocks processing a topic update in which it adds a transient entry while at > the same time failing heartbeats -- 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] [Updated] (IMPALA-7594) TestAutomaticCatalogInvalidation.test_local_catalog and test_v1_catalog still hitting timeout
[
https://issues.apache.org/jira/browse/IMPALA-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-7594:
--
Description:
Similar to IMPALA-7580, I hit this on a build of one of my patches when running
under ASAN. The branch had the fix for IMPALA-7580 in it (it's based off
038af345933fde4fbcc9bc524f4ca93bfc08c633):
{noformat}
custom_cluster.test_automatic_invalidation.TestAutomaticCatalogInvalidation.test_local_catalog
(from pytest)
Failing for the past 2 builds (Since Failed#3242 )
Took 30 sec.
add description
Error Message
assert 1537339209.989275 < 1537339209.65928 + where 1537339209.989275 =
() +where = time.time
Stacktrace
custom_cluster/test_automatic_invalidation.py:70: in test_local_catalog
self._run_test(cursor)
custom_cluster/test_automatic_invalidation.py:58: in _run_test
assert time.time() < timeout
E assert 1537339209.989275 < 1537339209.65928
E+ where 1537339209.989275 = ()
E+where = time.time
Standard Error
-- 2018-09-18 23:39:39,498 INFO MainThread: Starting cluster with command:
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/bin/start-impala-cluster.py
--cluster_size=3 --num_coordinators=3
--log_dir=/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests
--log_level=1 '--impalad_args="--invalidate_tables_timeout_s=20
--use_local_catalog" ' '--state_store_args="--statestore_update_frequency_ms=50
--statestore_priority_update_frequency_ms=50
--statestore_heartbeat_frequency_ms=50" '
'--catalogd_args="--invalidate_tables_timeout_s=20
--catalog_topic_mode=minimal" '
23:39:40 MainThread: Starting State Store logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/statestored.INFO
23:39:41 MainThread: Starting Catalog Service logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/catalogd.INFO
23:39:42 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad.INFO
23:39:43 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node1.INFO
23:39:44 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node2.INFO
23:39:47 MainThread: Found 3 impalad/1 statestored/1 catalogd process(es)
23:39:47 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
23:39:47 MainThread: Waiting for num_known_live_backends=3. Current value: 2
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25001
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25002
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Impala Cluster Running with 3 nodes (3 coordinators, 3
executors).
-- 2018-09-18 23:39:48,471 INFO MainThread: Found 3 impalad/1 statestored/1
catalogd process(es)
-- 2018-09-18 23:39:48,471 INFO MainThread: Getting metric:
statestore.live-backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25010
-- 2018-09-18 23:39:48,472 INFO MainThread: Metric
'statestore.live-backends' has reached desired value: 4
-- 2018-09-18 23:39:48,472 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
-- 2018-09-18 23:39:48,473 INFO MainThread: num_known_live_backends has
reached value: 3
-- 2018-09-18 23:39:48,473 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25001
-- 2018-09-18 23:39:48,474 INFO MainThread: num_known_live_backends has
reached value: 3
-- 2018-09-18 23:39:48,474 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25002
-- 2018-09-18 23:39:48,475 INFO MainThread: num_known_live_backends has
reached value: 3
-- connecting to: localhost:21000
-- 2018-09-18 23:39:48,475 ERRORMainThread: Failed to open transport
(tries_left=3)
Traceback (most recent call last):
File
"/data/jenkins/workspace/impala-private-parameterized/repos/Impala/infra/python/env/lib/python2.7/site-packages/impala/hiveserver2.py",
line 940, in _execute
return func(request)
File
[jira] [Updated] (IMPALA-7594) TestAutomaticCatalogInvalidation.test_local_catalog and test_v1_catalog still hitting timeout
[
https://issues.apache.org/jira/browse/IMPALA-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-7594:
--
Summary: TestAutomaticCatalogInvalidation.test_local_catalog and
test_v1_catalog still hitting timeout (was:
TestAutomaticCatalogInvalidation.test_local_catalog still hitting timeout)
> TestAutomaticCatalogInvalidation.test_local_catalog and test_v1_catalog still
> hitting timeout
> -
>
> Key: IMPALA-7594
> URL: https://issues.apache.org/jira/browse/IMPALA-7594
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 3.1.0
>Reporter: Tim Armstrong
>Assignee: Tianyi Wang
>Priority: Critical
> Labels: flaky
>
> Similar to IMPALA-7580, I hit this on a build of one of my patches when
> running under ASAN. The branch had the fix for IMPALA-7580 in it (it's based
> off 038af345933fde4fbcc9bc524f4ca93bfc08c633):
> {noformat}
> custom_cluster.test_automatic_invalidation.TestAutomaticCatalogInvalidation.test_local_catalog
> (from pytest)
> Failing for the past 2 builds (Since Failed#3242 )
> Took 30 sec.
> add description
> Error Message
> assert 1537339209.989275 < 1537339209.65928 + where 1537339209.989275 =
> () +where = time.time
> Stacktrace
> custom_cluster/test_automatic_invalidation.py:70: in test_local_catalog
> self._run_test(cursor)
> custom_cluster/test_automatic_invalidation.py:58: in _run_test
> assert time.time() < timeout
> E assert 1537339209.989275 < 1537339209.65928
> E+ where 1537339209.989275 = ()
> E+where = time.time
> Standard Error
> -- 2018-09-18 23:39:39,498 INFO MainThread: Starting cluster with
> command:
> /data/jenkins/workspace/impala-private-parameterized/repos/Impala/bin/start-impala-cluster.py
> --cluster_size=3 --num_coordinators=3
> --log_dir=/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests
> --log_level=1 '--impalad_args="--invalidate_tables_timeout_s=20
> --use_local_catalog" '
> '--state_store_args="--statestore_update_frequency_ms=50
> --statestore_priority_update_frequency_ms=50
> --statestore_heartbeat_frequency_ms=50" '
> '--catalogd_args="--invalidate_tables_timeout_s=20
> --catalog_topic_mode=minimal" '
> 23:39:40 MainThread: Starting State Store logging to
> /data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/statestored.INFO
> 23:39:41 MainThread: Starting Catalog Service logging to
> /data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/catalogd.INFO
> 23:39:42 MainThread: Starting Impala Daemon logging to
> /data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad.INFO
> 23:39:43 MainThread: Starting Impala Daemon logging to
> /data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node1.INFO
> 23:39:44 MainThread: Starting Impala Daemon logging to
> /data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node2.INFO
> 23:39:47 MainThread: Found 3 impalad/1 statestored/1 catalogd process(es)
> 23:39:47 MainThread: Getting num_known_live_backends from
> impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
> 23:39:47 MainThread: Waiting for num_known_live_backends=3. Current value: 2
> 23:39:48 MainThread: Getting num_known_live_backends from
> impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
> 23:39:48 MainThread: num_known_live_backends has reached value: 3
> 23:39:48 MainThread: Getting num_known_live_backends from
> impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25001
> 23:39:48 MainThread: num_known_live_backends has reached value: 3
> 23:39:48 MainThread: Getting num_known_live_backends from
> impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25002
> 23:39:48 MainThread: num_known_live_backends has reached value: 3
> 23:39:48 MainThread: Impala Cluster Running with 3 nodes (3 coordinators, 3
> executors).
> -- 2018-09-18 23:39:48,471 INFO MainThread: Found 3 impalad/1
> statestored/1 catalogd process(es)
> -- 2018-09-18 23:39:48,471 INFO MainThread: Getting metric:
> statestore.live-backends from
> impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25010
> -- 2018-09-18 23:39:48,472 INFO MainThread: Metric
> 'statestore.live-backends' has reached desired value: 4
> -- 2018-09-18 23:39:48,472 INFO MainThread: Getting
> num_known_live_backends from
> impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
> -- 2018-09-18 23:39:48,473 INFO MainThread: num_known_live_backends has
> reached value: 3
>
[jira] [Updated] (IMPALA-7594) TestAutomaticCatalogInvalidation.test_local_catalog still hitting timeout
[
https://issues.apache.org/jira/browse/IMPALA-7594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-7594:
--
Description:
Similar to IMPALA-7580, I hit this on a build of one of my patches when running
under ASAN. The branch had the fix for IMPALA-7580 in it (it's based off
038af345933fde4fbcc9bc524f4ca93bfc08c633):
{noformat}
custom_cluster.test_automatic_invalidation.TestAutomaticCatalogInvalidation.test_local_catalog
(from pytest)
Failing for the past 2 builds (Since Failed#3242 )
Took 30 sec.
add description
Error Message
assert 1537339209.989275 < 1537339209.65928 + where 1537339209.989275 =
() +where = time.time
Stacktrace
custom_cluster/test_automatic_invalidation.py:70: in test_local_catalog
self._run_test(cursor)
custom_cluster/test_automatic_invalidation.py:58: in _run_test
assert time.time() < timeout
E assert 1537339209.989275 < 1537339209.65928
E+ where 1537339209.989275 = ()
E+where = time.time
Standard Error
-- 2018-09-18 23:39:39,498 INFO MainThread: Starting cluster with command:
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/bin/start-impala-cluster.py
--cluster_size=3 --num_coordinators=3
--log_dir=/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests
--log_level=1 '--impalad_args="--invalidate_tables_timeout_s=20
--use_local_catalog" ' '--state_store_args="--statestore_update_frequency_ms=50
--statestore_priority_update_frequency_ms=50
--statestore_heartbeat_frequency_ms=50" '
'--catalogd_args="--invalidate_tables_timeout_s=20
--catalog_topic_mode=minimal" '
23:39:40 MainThread: Starting State Store logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/statestored.INFO
23:39:41 MainThread: Starting Catalog Service logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/catalogd.INFO
23:39:42 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad.INFO
23:39:43 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node1.INFO
23:39:44 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node2.INFO
23:39:47 MainThread: Found 3 impalad/1 statestored/1 catalogd process(es)
23:39:47 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
23:39:47 MainThread: Waiting for num_known_live_backends=3. Current value: 2
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25001
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25002
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Impala Cluster Running with 3 nodes (3 coordinators, 3
executors).
-- 2018-09-18 23:39:48,471 INFO MainThread: Found 3 impalad/1 statestored/1
catalogd process(es)
-- 2018-09-18 23:39:48,471 INFO MainThread: Getting metric:
statestore.live-backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25010
-- 2018-09-18 23:39:48,472 INFO MainThread: Metric
'statestore.live-backends' has reached desired value: 4
-- 2018-09-18 23:39:48,472 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
-- 2018-09-18 23:39:48,473 INFO MainThread: num_known_live_backends has
reached value: 3
-- 2018-09-18 23:39:48,473 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25001
-- 2018-09-18 23:39:48,474 INFO MainThread: num_known_live_backends has
reached value: 3
-- 2018-09-18 23:39:48,474 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25002
-- 2018-09-18 23:39:48,475 INFO MainThread: num_known_live_backends has
reached value: 3
-- connecting to: localhost:21000
-- 2018-09-18 23:39:48,475 ERRORMainThread: Failed to open transport
(tries_left=3)
Traceback (most recent call last):
File
"/data/jenkins/workspace/impala-private-parameterized/repos/Impala/infra/python/env/lib/python2.7/site-packages/impala/hiveserver2.py",
line 940, in _execute
return func(request)
File
[jira] [Created] (IMPALA-7594) TestAutomaticCatalogInvalidation.test_local_catalog still hitting timeout
Tim Armstrong created IMPALA-7594:
-
Summary: TestAutomaticCatalogInvalidation.test_local_catalog still
hitting timeout
Key: IMPALA-7594
URL: https://issues.apache.org/jira/browse/IMPALA-7594
Project: IMPALA
Issue Type: Bug
Components: Infrastructure
Affects Versions: Impala 3.1.0
Reporter: Tim Armstrong
Assignee: Tianyi Wang
Similar to IMPALA-7580, I hit this on a build of one of my patches. The branch
had the fix for IMPALA-7580 in it:
{noformat}
custom_cluster.test_automatic_invalidation.TestAutomaticCatalogInvalidation.test_local_catalog
(from pytest)
Failing for the past 2 builds (Since Failed#3242 )
Took 30 sec.
add description
Error Message
assert 1537339209.989275 < 1537339209.65928 + where 1537339209.989275 =
() +where = time.time
Stacktrace
custom_cluster/test_automatic_invalidation.py:70: in test_local_catalog
self._run_test(cursor)
custom_cluster/test_automatic_invalidation.py:58: in _run_test
assert time.time() < timeout
E assert 1537339209.989275 < 1537339209.65928
E+ where 1537339209.989275 = ()
E+where = time.time
Standard Error
-- 2018-09-18 23:39:39,498 INFO MainThread: Starting cluster with command:
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/bin/start-impala-cluster.py
--cluster_size=3 --num_coordinators=3
--log_dir=/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests
--log_level=1 '--impalad_args="--invalidate_tables_timeout_s=20
--use_local_catalog" ' '--state_store_args="--statestore_update_frequency_ms=50
--statestore_priority_update_frequency_ms=50
--statestore_heartbeat_frequency_ms=50" '
'--catalogd_args="--invalidate_tables_timeout_s=20
--catalog_topic_mode=minimal" '
23:39:40 MainThread: Starting State Store logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/statestored.INFO
23:39:41 MainThread: Starting Catalog Service logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/catalogd.INFO
23:39:42 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad.INFO
23:39:43 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node1.INFO
23:39:44 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-private-parameterized/repos/Impala/logs/custom_cluster_tests/impalad_node2.INFO
23:39:47 MainThread: Found 3 impalad/1 statestored/1 catalogd process(es)
23:39:47 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
23:39:47 MainThread: Waiting for num_known_live_backends=3. Current value: 2
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25001
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25002
23:39:48 MainThread: num_known_live_backends has reached value: 3
23:39:48 MainThread: Impala Cluster Running with 3 nodes (3 coordinators, 3
executors).
-- 2018-09-18 23:39:48,471 INFO MainThread: Found 3 impalad/1 statestored/1
catalogd process(es)
-- 2018-09-18 23:39:48,471 INFO MainThread: Getting metric:
statestore.live-backends from
impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25010
-- 2018-09-18 23:39:48,472 INFO MainThread: Metric
'statestore.live-backends' has reached desired value: 4
-- 2018-09-18 23:39:48,472 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25000
-- 2018-09-18 23:39:48,473 INFO MainThread: num_known_live_backends has
reached value: 3
-- 2018-09-18 23:39:48,473 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25001
-- 2018-09-18 23:39:48,474 INFO MainThread: num_known_live_backends has
reached value: 3
-- 2018-09-18 23:39:48,474 INFO MainThread: Getting num_known_live_backends
from impala-ec2-centos74-m5-4xlarge-ondemand-01b4.vpc.cloudera.com:25002
-- 2018-09-18 23:39:48,475 INFO MainThread: num_known_live_backends has
reached value: 3
-- connecting to: localhost:21000
-- 2018-09-18 23:39:48,475 ERRORMainThread: Failed to open transport
(tries_left=3)
Traceback (most recent call last):
File
[jira] [Created] (IMPALA-7593) test_automatic_invalidation failing in S3
Thomas Tauber-Marshall created IMPALA-7593:
--
Summary: test_automatic_invalidation failing in S3
Key: IMPALA-7593
URL: https://issues.apache.org/jira/browse/IMPALA-7593
Project: IMPALA
Issue Type: Bug
Affects Versions: Impala 3.1.0
Reporter: Thomas Tauber-Marshall
Assignee: Tianyi Wang
Note that the build has the fix for IMPALA-7580
{noformat}
4:59:01 ___ TestAutomaticCatalogInvalidation.test_v1_catalog
___
04:59:01 custom_cluster/test_automatic_invalidation.py:63: in test_v1_catalog
04:59:01 self._run_test(cursor)
04:59:01 custom_cluster/test_automatic_invalidation.py:58: in _run_test
04:59:01 assert time.time() < timeout
04:59:01 E assert 1537355634.805718 < 1537355634.394429
04:59:01 E+ where 1537355634.805718 = ()
04:59:01 E+where = time.time
04:59:01 Captured stderr setup
-
04:59:01 -- 2018-09-19 04:13:22,796 INFO MainThread: Starting cluster with
command:
/data/jenkins/workspace/impala-asf-master-core-asan/repos/Impala/bin/start-impala-cluster.py
--cluster_size=3 --num_coordinators=3
--log_dir=/data/jenkins/workspace/impala-asf-master-core-asan/repos/Impala/logs/custom_cluster_tests
--log_level=1 '--impalad_args="--invalidate_tables_timeout_s=20" '
'--state_store_args="--statestore_update_frequency_ms=50
--statestore_priority_update_frequency_ms=50
--statestore_heartbeat_frequency_ms=50" '
'--catalogd_args="--invalidate_tables_timeout_s=20" '
04:59:01 04:13:23 MainThread: Starting State Store logging to
/data/jenkins/workspace/impala-asf-master-core-asan/repos/Impala/logs/custom_cluster_tests/statestored.INFO
04:59:01 04:13:23 MainThread: Starting Catalog Service logging to
/data/jenkins/workspace/impala-asf-master-core-asan/repos/Impala/logs/custom_cluster_tests/catalogd.INFO
04:59:01 04:13:24 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-asf-master-core-asan/repos/Impala/logs/custom_cluster_tests/impalad.INFO
04:59:01 04:13:25 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-asf-master-core-asan/repos/Impala/logs/custom_cluster_tests/impalad_node1.INFO
04:59:01 04:13:26 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-asf-master-core-asan/repos/Impala/logs/custom_cluster_tests/impalad_node2.INFO
04:59:01 04:13:29 MainThread: Found 3 impalad/1 statestored/1 catalogd
process(es)
04:59:01 04:13:29 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25000
04:59:01 04:13:29 MainThread: Waiting for num_known_live_backends=3. Current
value: 0
04:59:01 04:13:30 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25000
04:59:01 04:13:30 MainThread: Waiting for num_known_live_backends=3. Current
value: 1
04:59:01 04:13:31 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25000
04:59:01 04:13:31 MainThread: Waiting for num_known_live_backends=3. Current
value: 2
04:59:01 04:13:32 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25000
04:59:01 04:13:32 MainThread: num_known_live_backends has reached value: 3
04:59:01 04:13:32 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25001
04:59:01 04:13:32 MainThread: num_known_live_backends has reached value: 3
04:59:01 04:13:32 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25002
04:59:01 04:13:32 MainThread: num_known_live_backends has reached value: 3
04:59:01 04:13:32 MainThread: Impala Cluster Running with 3 nodes (3
coordinators, 3 executors).
04:59:01 -- 2018-09-19 04:13:33,034 INFO MainThread: Found 3 impalad/1
statestored/1 catalogd process(es)
04:59:01 -- 2018-09-19 04:13:33,034 INFO MainThread: Getting metric:
statestore.live-backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25010
04:59:01 -- 2018-09-19 04:13:33,036 INFO MainThread: Metric
'statestore.live-backends' has reached desired value: 4
04:59:01 -- 2018-09-19 04:13:33,036 INFO MainThread: Getting
num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25000
04:59:01 -- 2018-09-19 04:13:33,037 INFO MainThread:
num_known_live_backends has reached value: 3
04:59:01 -- 2018-09-19 04:13:33,037 INFO MainThread: Getting
num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-1860.vpc.cloudera.com:25001
04:59:01 -- 2018-09-19 04:13:33,038 INFO MainThread:
num_known_live_backends has reached value: 3
04:59:01 -- 2018-09-19 04:13:33,038 INFO MainThread: Getting
[jira] [Commented] (IMPALA-7581) Hang in buffer-pool-test
[ https://issues.apache.org/jira/browse/IMPALA-7581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620813#comment-16620813 ] Tim Armstrong commented on IMPALA-7581: --- I just discovered that I had a buffer-pool-test process sitting in the background on my machine for 40 hours, so maybe I did reproduce it after all. I wasn't able to pstack unfortunately, but that suggests it's worth trying harder to repro. > Hang in buffer-pool-test > > > Key: IMPALA-7581 > URL: https://issues.apache.org/jira/browse/IMPALA-7581 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 3.1.0 >Reporter: Thomas Tauber-Marshall >Assignee: Tim Armstrong >Priority: Blocker > Labels: broken-build, flaky > > We have observed a hang in buffer-pool-test an ASAN build. Unfortunately, no > logs were generated with any info about what might have happened. -- 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] [Resolved] (IMPALA-7588) incorrect HS2 null handling introduced by IMPALA-7477
[
https://issues.apache.org/jira/browse/IMPALA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong resolved IMPALA-7588.
---
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> incorrect HS2 null handling introduced by IMPALA-7477
> -
>
> Key: IMPALA-7588
> URL: https://issues.apache.org/jira/browse/IMPALA-7588
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Reporter: Tim Armstrong
>Assignee: Tim Armstrong
>Priority: Blocker
> Labels: correctness
> Fix For: Impala 3.1.0
>
>
> [~boroknagyz] reported this issue with the HS2 endpoint:
> Reproduction:
> {noformat}
> create table null_table (int_field int, float_field float, double_field
> double, string_field string);
> insert into table null_table values (1, 3.14, 3.14, 'abc'), (2, 4.12, 4.12,
> 'def'), (NULL, NULL, NULL, NULL);
> {noformat}
> From JDBC client (only tried Hive JDBC client)
> {noformat}
> select * from null_table;
> 0 | 0.0 | 0.0 | null
> 2 | 4.12 | 4.12 | 'def'
> 0 | 0.0 | 0.0 |
> {noformat}
> The bug is with handling of nulls in the conversion functions, specifically
> output_row_idx isn't incremented.
--
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-7588) incorrect HS2 null handling introduced by IMPALA-7477
[
https://issues.apache.org/jira/browse/IMPALA-7588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16620613#comment-16620613
]
Zoltán Borók-Nagy commented on IMPALA-7588:
---
I pushed in the revert of IMPALA-7477 to the ASF repo:
[https://github.com/apache/impala/commit/109028e89ce27880cc2ef69a7a5032c05df4d4df]
> incorrect HS2 null handling introduced by IMPALA-7477
> -
>
> Key: IMPALA-7588
> URL: https://issues.apache.org/jira/browse/IMPALA-7588
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Reporter: Tim Armstrong
>Assignee: Tim Armstrong
>Priority: Blocker
> Labels: correctness
>
> [~boroknagyz] reported this issue with the HS2 endpoint:
> Reproduction:
> {noformat}
> create table null_table (int_field int, float_field float, double_field
> double, string_field string);
> insert into table null_table values (1, 3.14, 3.14, 'abc'), (2, 4.12, 4.12,
> 'def'), (NULL, NULL, NULL, NULL);
> {noformat}
> From JDBC client (only tried Hive JDBC client)
> {noformat}
> select * from null_table;
> 0 | 0.0 | 0.0 | null
> 2 | 4.12 | 4.12 | 'def'
> 0 | 0.0 | 0.0 |
> {noformat}
> The bug is with handling of nulls in the conversion functions, specifically
> output_row_idx isn't incremented.
--
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] [Created] (IMPALA-7592) Planner should correctly estimate UnionNode host count
Balazs Jeszenszky created IMPALA-7592: - Summary: Planner should correctly estimate UnionNode host count Key: IMPALA-7592 URL: https://issues.apache.org/jira/browse/IMPALA-7592 Project: IMPALA Issue Type: Improvement Components: Frontend Affects Versions: Impala 3.0 Reporter: Balazs Jeszenszky Currently, the planner estimates UnionNode host count to be the maximum of all its children. In reality, scheduler will put these nodes on the union of its inputs' hosts. We should update the planner to correctly account for this behaviour. -- 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
