This is an automated email from the ASF dual-hosted git repository.

dbecker pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/impala.git

commit 589dbd6f1a1247c365fa794e5b7ed992c2e1f2ab
Author: Fang-Yu Rao <[email protected]>
AuthorDate: Mon Aug 5 15:20:18 2024 -0700

    IMPALA-13276: Revise the documentation of 'RUNTIME_FILTER_WAIT_TIME_MS'
    
    This patch revises the documentation of the query option
    'RUNTIME_FILTER_WAIT_TIME_MS' as well as the code comment for the same
    query option to make its meaning clearer.
    
    Change-Id: Ic98e23a902a65e4fa41a628d4a3edb1894660fb4
    Reviewed-on: http://gerrit.cloudera.org:8080/21644
    Tested-by: Impala Public Jenkins <[email protected]>
    Reviewed-by: Csaba Ringhofer <[email protected]>
---
 common/thrift/Query.thrift                         |  6 ++++--
 docs/topics/impala_runtime_filter_wait_time_ms.xml |  7 +++++++
 docs/topics/impala_runtime_filtering.xml           | 12 ++++++------
 3 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/common/thrift/Query.thrift b/common/thrift/Query.thrift
index 02a3e6f1b..80bf4a90a 100644
--- a/common/thrift/Query.thrift
+++ b/common/thrift/Query.thrift
@@ -238,8 +238,10 @@ struct TQueryOptions {
   // be rounded up to the nearest power of two.
   38: optional i32 runtime_bloom_filter_size = 1048576
 
-  // Time in ms to wait until runtime filters are delivered. If 0, the default 
defined
-  // by the startup flag of the same name is used.
+  // Time in ms to wait until runtime filters are delivered. Note that the 
wait time for
+  // a runtime filter is with respect to the start of processing the query in 
the given
+  // executor instead of the beginning of the Open phase of a scan node. If 0, 
the
+  // default defined by the startup flag of the same name is used.
   39: optional i32 runtime_filter_wait_time_ms = 0
 
   // If true, per-row runtime filtering is disabled
diff --git a/docs/topics/impala_runtime_filter_wait_time_ms.xml 
b/docs/topics/impala_runtime_filter_wait_time_ms.xml
index b81f70440..b23998304 100644
--- a/docs/topics/impala_runtime_filter_wait_time_ms.xml
+++ b/docs/topics/impala_runtime_filter_wait_time_ms.xml
@@ -40,6 +40,13 @@ under the License.
       adjusts the settings for the runtime filtering feature.
       It specifies a time in milliseconds that each scan node waits for
       runtime filters to be produced by other plan fragments.
+      Note that the wait time for a runtime filter is with respect to the 
start of
+      processing the query in the given executor instead of the beginning of 
the Open
+      phase of a scan node. For instance, a scan node could start so late that 
at the
+      beginning of the Open phase of the scan node, the amount of time passed 
since the
+      start of query processing was already greater than the value of
+      <codeph>RUNTIME_FILTER_WAIT_TIME_MS</codeph>. In such a case, even 
though the
+      runtime filter has not arrived yet, the scan node will not wait any 
longer.
     </p>
 
     <p conref="../shared/impala_common.xml#common/type_integer"/>
diff --git a/docs/topics/impala_runtime_filtering.xml 
b/docs/topics/impala_runtime_filtering.xml
index ec519d022..8e27b4e82 100644
--- a/docs/topics/impala_runtime_filtering.xml
+++ b/docs/topics/impala_runtime_filtering.xml
@@ -242,12 +242,12 @@ under the License.
         <codeph>RUNTIME_FILTER_WAIT_TIME_MS</codeph> query option.
       </p>
       <p>
-        By default, each scan node waits for up to 1 second (1000 milliseconds)
-        for filters to arrive. If all filters have not arrived within the
-        specified interval, the scan node proceeds, using whatever filters
-        did arrive to help avoid reading unnecessary data. If a filter arrives
-        after the scan node begins reading data, the scan node applies that
-        filter to the data that is read after the filter arrives, but not to
+        The time is counted from the start of executing the query — see the 
query
+        option's doc page for details.
+        If all filters have not arrived within the specified interval, the 
scan node
+        proceeds, using whatever filters did arrive to help avoid reading 
unnecessary
+        data. If a filter arrives after the scan node begins reading data, the 
scan node
+        applies that filter to the data that is read after the filter arrives, 
but not to
         the data that was already read.
       </p>
       <p>

Reply via email to