diff --git a/docs/en/administrator-guide/runtime-filter.md b/docs/en/administrator-guide/runtime-filter.md index 5db59cc29b..12107049da 100644 --- a/docs/en/administrator-guide/runtime-filter.md +++ b/docs/en/administrator-guide/runtime-filter.md @@ -81,7 +81,7 @@ If the filter condition (Runtime Filter) can be pushed down to the storage engin ``` It can be seen that, unlike predicate push-down and partition cutting, Runtime Filter is a filter condition dynamically generated at runtime, that is, when the query is run, the join on clause is parsed to determine the filter expression, and the expression is broadcast to ScanNode that is reading the left table , Thereby reducing the amount of scanned data, thereby reducing the number of probe hash table, avoiding unnecessary I/O and network transmission. -Runtime Filter is mainly used to optimize joins for large tables. If the amount of data in the left table is too small, or the amount of data in the right table is too large, the Runtime Filter may not achieve the expected effect. +Runtime Filter is mainly used to optimize joins between a large table and a small table. If the amount of data in the left table is too small, or the amount of data in the right table is too large, the Runtime Filter may not achieve the expected effect. ## Usage diff --git a/docs/zh-CN/administrator-guide/runtime-filter.md b/docs/zh-CN/administrator-guide/runtime-filter.md index 2e6d897c3f..ef34b155d0 100644 --- a/docs/zh-CN/administrator-guide/runtime-filter.md +++ b/docs/zh-CN/administrator-guide/runtime-filter.md @@ -81,7 +81,7 @@ Runtime Filter在查询规划时生成，在HashJoinNode中构建，在ScanNode ``` 可见，和谓词下推、分区裁剪不同，Runtime Filter是在运行时动态生成的过滤条件，即在查询运行时解析join on clause确定过滤表达式，并将表达式广播给正在读取左表的ScanNode，从而减少扫描的数据量，进而减少probe hash table的次数，避免不必要的I/O和网络传输。 -Runtime Filter主要用于优化针对大表的join，如果左表的数据量太小，或者右表的数据量太大，则Runtime Filter可能不会取得预期效果。 +Runtime Filter主要用于大表join小表的优化，如果左表的数据量太小，或者右表的数据量太大，则Runtime Filter可能不会取得预期效果。 ## 使用方式 diff --git a/docs/zh-CN/administrator-guide/vectorized-execution-engine.md b/docs/zh-CN/administrator-guide/vectorized-execution-engine.md index acfa4a383d..d2272a5bf6 100644 --- a/docs/zh-CN/administrator-guide/vectorized-execution-engine.md +++ b/docs/zh-CN/administrator-guide/vectorized-execution-engine.md @@ -50,7 +50,7 @@ Database Systems](https://web.stanford.edu/class/cs346/2015/notes/old/column.pdf ![image.png](/images/vectorized-execution-engine2.png) 1. 重新组织内存的数据结构，用**Column**替换**Tuple**，提高了计算时Cache亲和度，分支预测与预取内存的友好度 -2. 分批进行类型判断，这单批次内用确定的类型。将每一行类型判断的虚函数开销分摊到批量级别。 +2. 分批进行类型判断，在本次批次中都使用类型判断时确定的类型。将每一行类型判断的虚函数开销分摊到批量级别。 3. 通过批级别的类型判断，消除了虚函数的调用，让编译器有函数内联以及SIMD优化的机会 从而大大提高了CPU在SQL执行时的效率，提升了SQL查询的性能。 @@ -100,7 +100,7 @@ set batch_size = 4096; ## 与行存执行引擎的部分差异 -在绝大多数场景之中，用户只需要默认打开session变量的开关就可以透明的使向量化执行引擎并且得到SQL执行的性能提升。但是，**目前的向量化执行引擎在下面一些微小的细节上与原先的行存执行引擎存在不同，需要使用者知晓**。这部分区别分为两类 +在绝大多数场景之中，用户只需要默认打开session变量的开关，就可以透明地使用向量化执行引擎，并且使SQL执行的性能得到提升。但是，**目前的向量化执行引擎在下面一些微小的细节上与原先的行存执行引擎存在不同，需要使用者知晓**。这部分区别分为两类 * **a类** ：行存执行引擎需要被废弃和不推荐使用或依赖的功能 * **b类**： 短期没有在向量化执行引擎上得到支持，但后续会得到开发支持的功能