[ 
https://issues.apache.org/jira/browse/IMPALA-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16693964#comment-16693964
 ] 

ASF subversion and git services commented on IMPALA-7829:
---------------------------------------------------------

Commit 9ef9dacaf764aac869c8072eee823d1129657cf4 in impala's branch 
refs/heads/master from Michael Ho
[ https://git-wip-us.apache.org/repos/asf?p=impala.git;h=9ef9dac ]

IMPALA-7829: Mark a fragment instance as done only after Close() is called

As shown in IMPALA-7828. there is some non-determinism on whether the errors
detected in FragmentInstanceState::Close() will show up in the final profile
sent to the coordinator. The reason is that the current code marks a fragment
instance as "done" after ExecInternal() completes but before Close() is called.
There is a window between when the final status report is sent and when Close()
finishes.

This change fixes the problem by not sending the final report until Close()
is called. This has no implication on the first row available time for normal
queries. It may slightly lengthen the first row available time for DML queries.

Testing done: Updated udf-no-expr-rewrite.test to exercise this test

Perf run on an 8 node clusters didn't show any regression:

TPCH-300
+------------+-----------------------+---------+------------+------------+----------------+
| Workload   | File Format           | Avg (s) | Delta(Avg) | GeoMean(s) | 
Delta(GeoMean) |
+------------+-----------------------+---------+------------+------------+----------------+
| TPCH(_300) | parquet / none / none | 23.94   | -2.05%     | 12.55      | 
-2.62%         |
+------------+-----------------------+---------+------------+------------+----------------+

Small concurrency
+-------------------------+-----------------------+---------+------------+------------+----------------+
| Workload                | File Format           | Avg (s) | Delta(Avg) | 
GeoMean(s) | Delta(GeoMean) |
+-------------------------+-----------------------+---------+------------+------------+----------------+
| TPCDS-UNMODIFIED(_1000) | parquet / none / none | 6.89    | -0.66%     | 6.62 
      | +0.41%         |
+-------------------------+-----------------------+---------+------------+------------+----------------+

Medium concurrency
+-------------------------+-----------------------+---------+------------+------------+----------------+
| Workload                | File Format           | Avg (s) | Delta(Avg) | 
GeoMean(s) | Delta(GeoMean) |
+-------------------------+-----------------------+---------+------------+------------+----------------+
| TPCDS-UNMODIFIED(_1000) | parquet / none / none | 55.57   | -1.04%     | 
55.27      | -0.98%         |
+-------------------------+-----------------------+---------+------------+------------+----------------+

Change-Id: I61618854ae3f4e7ef20028dcb0ff5cbcfa8adb01
Reviewed-on: http://gerrit.cloudera.org:8080/11939
Reviewed-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>
Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com>


> Send the final profile only after all fragment instances have been closed
> -------------------------------------------------------------------------
>
>                 Key: IMPALA-7829
>                 URL: https://issues.apache.org/jira/browse/IMPALA-7829
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Distributed Exec
>    Affects Versions: Impala 3.2.0
>            Reporter: Michael Ho
>            Assignee: Michael Ho
>            Priority: Critical
>
> As shown in IMPALA-7828. there is some non-determinism on whether the errors 
> detected in {{FragmentInstanceState::Close()}} will show up in the final 
> profile sent to the coordinator. The reason is that the current code marks a 
> fragment instance "done" after {{ExecInternal()}} completes but before 
> {{Close()}} is called. There is a window in between when the final status 
> report may be sent before {{Close()}} finishes. We should consider not 
> sending the final report until {{Close()}} is done but we probably need to 
> understand whether it has any implication to the overall reported query 
> execution time. It should have no effect to the "First Rows Available" time 
> for a query.



--
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

Reply via email to