Joe McDonnell created IMPALA-15546:
--------------------------------------
Summary: bin/run-workload.py's table of query results can be the
wrong order
Key: IMPALA-15546
URL: https://issues.apache.org/jira/browse/IMPALA-15546
Project: IMPALA
Issue Type: Bug
Components: Infrastructure
Affects Versions: Impala 5.0.0
Reporter: Joe McDonnell
At the end of execution, bin/run-workload.py outputs a table like this:
{noformat}
10:31:58 +----------+---------------------+----------------+-----------+
10:31:58 | Query | Start Time | Time Taken (s) | Client ID |
10:31:58 +----------+---------------------+----------------+-----------+
10:31:58 | TPCH-Q1 | 2026-10-07 17:22:57 | 8.43 | 1 |
10:31:59 | TPCH-Q1 | 2026-10-07 17:23:05 | 2.08 | 1 |
10:31:59 | TPCH-Q1 | 2026-10-07 17:23:07 | 2.09 | 1 |
10:31:59 | TPCH-Q1 | 2026-10-07 17:23:09 | 2.06 | 1 |
10:31:59 | TPCH-Q1 | 2026-10-07 17:23:12 | 2.10 | 1 |
...{noformat}
It seems that the table should be displaying in the order that the queries ran.
Sometimes that is true, but for short queries under a second, it is not. After
seeing issues, I annotated the output with the iteration number, and it is not
always in order:
{noformat}
13:17:48 | TPCH-Q10 | 2026-10-12 20:15:43 | 0.77 | 1 | 0
|
13:17:48 | TPCH-Q10 | 2026-10-12 20:15:44 | 0.59 | 1 | 1
|
13:17:48 | TPCH-Q10 | 2026-10-12 20:15:45 | 0.51 | 1 | 3
|
13:17:48 | TPCH-Q10 | 2026-10-12 20:15:45 | 0.58 | 1 | 2
|
13:17:48 | TPCH-Q10 | 2026-10-12 20:15:46 | 0.53 | 1 | 4
|
13:17:48 | TPCH-Q10 | 2026-10-12 20:15:47 | 0.52 | 1 | 6
|
13:17:48 | TPCH-Q10 | 2026-10-12 20:15:47 | 0.53 | 1 | 5
|{noformat}
We are sorting the prettytable by "Client ID" (which is always 1). In theory,
it should not consider other columns, but in practice it must be considering
the content of other columns. Since the timestamps for subsecond queries match,
it seems to sort by Time Taken. Without the sort, the table is fine.
We want this table to be in the order that the queries actually ran, as it is
very deceptive otherwise.
This doesn't impact the produced JSON file or any subsequent analysis.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
