Code coverage builds are slower than release or debug builds. This
patch gives test_hash_join_timer extra time so this test doesn't cause
code coverage builds don't fail in Jenkins.
Change-Id: I5598e073d779f744d79c5292e80a8ed8f6aa9548
Reviewed-on: http://gerrit.cloudera.org:8080/2608
Reviewed-by: Michael Brown <mikeb@cloudera.com>
Tested-by: Internal Jenkins
Because of IMPALA-2407, we use Linux's COARSE clockid_t on EC2.
However, this has a resolution between 1 and 10 milliseconds, and so
cannot be trusted to measure lower bounds as low as those in
test_hash_join_timer.py.
This is a temporary workaround.
Change-Id: I1332b1d9aede129ea6c508e40e20960fad9414a8
Reviewed-on: http://gerrit.cloudera.org:8080/2298
Reviewed-by: Tim Armstrong <tarmstrong@cloudera.com>
Reviewed-by: Dan Hecht <dhecht@cloudera.com>
Tested-by: Internal Jenkins
The time reported in the query profile for "ms" should be:
123.456ms
The time parsing in the test was based on above format.
However, the intial patch of IMPALA-1800 trucated the time to:
123ms
That caused the time parsing to fail.
In this fix, the time parsing is enhanced to handle this.
Change-Id: I4a38797e6c88d7101e53df5f69d9deab7c1f0819
Reviewed-on: http://gerrit.cloudera.org:8080/1218
Reviewed-by: Alan Choi <alan@cloudera.com>
Tested-by: Internal Jenkins
The definition of "local time" is the wall clock time where this exec
node is processing and it is not blocked by any of its children.
The join node has two execution models:
1. The entire join execution is in a single thread.
2. The build side is executed on a different thread while the main
thread opens the probe (left) child.
In case 1, the "local time" spent in this node is as simple as:
total_time - left child time - right child time
Because the entire right child time blocks the execution, the right
child time is the same as right_child_blocking_stop_watch_.
Case 2 is more complicated. The build thread is started first and
then the main thread will "open" the left child. When the left child
is ready (i.e. Open() returned), the main thread will wait for the
build thread to finish. Because the left child is always executed in
the main thread, all the left child time should not be counted
towards the hash join "local time".
For the right child (the build side), the child time in the build
thread up to the point when the left child Open() returns should not
be counted towards the hash join local time. This time period
completely overlaps with the left child time. From the time when left
child Open() returned, the right child time should be removed from
the total time because this is the only child that is blocking the
join execution.
Here's the calculation:
total_time - left child time - (right child time - overlapped
period)
The "overlapped period" is measured by a stop watch. Using this
overlap method, both children's "Prepare" time are also excluded.
The "local time" for the hash join node is now reported by a "derived counter"
using the above equation.
Change-Id: Icd518ca8e346836f010f663a2a1713b7a41ad0fc
Reviewed-on: http://gerrit.cloudera.org:8080/1170
Reviewed-by: Casey Ching <casey@cloudera.com>
Tested-by: Internal Jenkins
