[
https://issues.apache.org/jira/browse/IMPALA-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17071956#comment-17071956
]
Csaba Ringhofer commented on IMPALA-9584:
-----------------------------------------
>I think this is probably somehow indirectly caused by IMPALA-8005 randomising
>the exchanges.
Ah, that explains why it came up often recently.
>We're checking too many significant figures, really
In the AVG() case this is true, as double is involved, but in all other cases
timestamp functions should be deterministic with nanosec precision. I wouldn't
make the tests "weaker" for the sake of AVG, which is probably not used too
often with timestamps anyway.
I see two solutions:
- short term: Remove avg(timestamp_col) from the test, I don't think that it is
crucial here, e.g. max could be also used. I grepped for avg(timestamp_col) and
it is only used in this file in 2 tests.
- long term: Change the accumulator in the intermediate format of
AVG(TIMESTAMP) see IMPALA-7472. (I wrote decimal there, but two integers for
day_sum and nano_sum could be probably faster).
> test_analytic_fns is flaky (small fractional differences in AVG)
> ----------------------------------------------------------------
>
> Key: IMPALA-9584
> URL: https://issues.apache.org/jira/browse/IMPALA-9584
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Reporter: Csaba Ringhofer
> Priority: Major
> Labels: flaky-test
>
> The issue occurred here:
> https://jenkins.impala.io/job/ubuntu-16.04-dockerised-tests/2065/testReport/query_test.test_queries/TestQueries/test_analytic_fns_protocol__hs2___exec_option____batch_size___0___num_nodes___0___disable_codegen_rows_threshold___0___disable_codegen___False___abort_on_error___1___exec_single_node_rows_threshold___0____table_format__parquet_none_/
> The same test failed with all protocols.
> Failing query:
> https://github.com/apache/impala/blob/ebbe52b4bed944d3012e3679dc984827ce11d5a8/testdata/workloads/functional-query/queries/QueryTest/analytic-fns.test#L2
> Errors are like (hs2):
> 2009,3,6,3.666666666666667,2009-03-01 20:12:00.475000,'0','8' !=
> 2009,3,6,3.66666666667,2009-03-01 20:12:00.474999,'0','8'
> I think that the problem is not the difference in the 4th double column, as
> that depends on the client used and we do not require complete match during
> comparison. So the problem is likely to be the timestamp in the 5th column.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
