EmmyMiao87 commented on a change in pull request #7645:
URL: https://github.com/apache/incubator-doris/pull/7645#discussion_r780100487
##########
File path: docs/zh-CN/administrator-guide/runtime-filter.md
##########
@@ -138,6 +138,9 @@ set runtime_filter_type=7;
- 默认只有右表数据行数少于1024才会下推（可通过session变量中的`runtime_filter_max_in_num`调整）。
- 目前IN predicate已实现合并方法。
- 当同时指定In
predicate和其他filter，并且in的过滤数值没达到runtime_filter_max_in_num时，会尝试把其他filter去除掉。原因是In
predicate是精确的过滤条件，即使没有其他filter也可以高效过滤，如果同时使用则其他filter会做无用功。目前仅在Runtime
filter的生产者和消费者处于同一个fragment时才会有去除非in filter的逻辑。
+- **IN or Bloom Filter**: 根据右表的值的行数来判断使用IN predicate还是Bloom Filter
Review comment:
Put it above of all ~
##########
File path: docs/zh-CN/administrator-guide/runtime-filter.md
##########
@@ -138,6 +138,9 @@ set runtime_filter_type=7;
- 默认只有右表数据行数少于1024才会下推（可通过session变量中的`runtime_filter_max_in_num`调整）。
- 目前IN predicate已实现合并方法。
- 当同时指定In
predicate和其他filter，并且in的过滤数值没达到runtime_filter_max_in_num时，会尝试把其他filter去除掉。原因是In
predicate是精确的过滤条件，即使没有其他filter也可以高效过滤，如果同时使用则其他filter会做无用功。目前仅在Runtime
filter的生产者和消费者处于同一个fragment时才会有去除非in filter的逻辑。
+- **IN or Bloom Filter**: 根据右表的值的行数来判断使用IN predicate还是Bloom Filter
Review comment:
```suggestion
- **IN or Bloom Filter**: 根据右表在执行过程中的真实行数，由系统自动判断使用 IN predicate 还是 Bloom
Filter
```
##########
File path: fe/fe-core/src/test/java/org/apache/doris/planner/QueryPlanTest.java
##########
@@ -1366,23 +1366,15 @@ public void testRuntimeFilterMode() throws Exception {
queryStr = "explain select * from jointest t2, jointest t1 where t1.k1
<=> t2.k1";
Deencapsulation.setField(connectContext.getSessionVariable(),
"runtimeFilterMode", "LOCAL");
- Deencapsulation.setField(connectContext.getSessionVariable(),
"runtimeFilterType", 7);
+ Deencapsulation.setField(connectContext.getSessionVariable(),
"runtimeFilterType", 15);
Review comment:
What is the main purpose of this single test?
Type=15 is meaningless, writing this way will give users a wrong guide.
Can I change the type? Such as 8
##########
File path: docs/en/administrator-guide/runtime-filter.md
##########
@@ -138,6 +138,9 @@ set runtime_filter_type=7;
- By default, only the number of data rows in the right table is less than
1024 will be pushed down (can be adjusted by `runtime_filter_max_in_num` in the
session variable).
- Currently IN predicate already implement a merge method.
- When IN predicate and other filters are specified at the same time, and
the filtering value of IN predicate does not reach runtime_filter_max_in_num
will try to remove other filters. The reason is that IN predicate is an
accurate filtering condition. Even if there is no other filter, it can filter
efficiently. If it is used at the same time, other filters will do useless
work. Currently, only when the producer and consumer of the runtime filter are
in the same fragment can there be logic to remove the Non-IN predicate.
+- **IN_OR_BLOOM FILTER**:
Review comment:
same as above
##########
File path: fe/fe-core/src/test/java/org/apache/doris/planner/QueryPlanTest.java
##########
@@ -1429,6 +1421,64 @@ public void testRuntimeFilterType() throws Exception {
explainString = UtFrameUtils.getSQLPlanOrErrorMsg(connectContext,
queryStr);
Assert.assertTrue(explainString.contains("runtime filters: RF000[in]
<- `t1`.`k1`, RF001[bloom] <- `t1`.`k1`, RF002[min_max] <- `t1`.`k1`"));
Assert.assertTrue(explainString.contains("runtime filters: RF000[in]
-> `t2`.`k1`, RF001[bloom] -> `t2`.`k1`, RF002[min_max] -> `t2`.`k1`"));
+
+ Deencapsulation.setField(connectContext.getSessionVariable(),
"runtimeFilterType", 8);
+ explainString = UtFrameUtils.getSQLPlanOrErrorMsg(connectContext,
queryStr);
+ Assert.assertTrue(explainString.contains("runtime filters:
RF000[in_or_bloom] <- `t1`.`k1`"));
+ Assert.assertTrue(explainString.contains("runtime filters:
RF000[in_or_bloom] -> `t2`.`k1`"));
+
+ Deencapsulation.setField(connectContext.getSessionVariable(),
"runtimeFilterType", 9);
Review comment:
The type value 9 is not used in the scene, you can make a note in the
front. This case is only used to test the logical correctness. In fact, the
value of type is meaningless.
##########
File path:
fe/fe-core/src/test/java/org/apache/doris/qe/RuntimeFilterTypeHelperTest.java
##########
@@ -50,6 +50,30 @@ public void testNormal() throws DdlException {
runtimeFilterType = "IN,BLOOM_FILTER,MIN_MAX";
Assert.assertEquals(new Long(7L),
RuntimeFilterTypeHelper.encode(runtimeFilterType));
+ runtimeFilterType = "IN_OR_BLOOM_FILTER";
+ Assert.assertEquals(new Long(8L),
RuntimeFilterTypeHelper.encode(runtimeFilterType));
+
+ runtimeFilterType = "IN,IN_OR_BLOOM_FILTER";
+ Assert.assertEquals(new Long(9L),
RuntimeFilterTypeHelper.encode(runtimeFilterType));
Review comment:
same as above
##########
File path: docs/zh-CN/administrator-guide/runtime-filter.md
##########
@@ -138,6 +138,9 @@ set runtime_filter_type=7;
- 默认只有右表数据行数少于1024才会下推（可通过session变量中的`runtime_filter_max_in_num`调整）。
- 目前IN predicate已实现合并方法。
- 当同时指定In
predicate和其他filter，并且in的过滤数值没达到runtime_filter_max_in_num时，会尝试把其他filter去除掉。原因是In
predicate是精确的过滤条件，即使没有其他filter也可以高效过滤，如果同时使用则其他filter会做无用功。目前仅在Runtime
filter的生产者和消费者处于同一个fragment时才会有去除非in filter的逻辑。
+- **IN or Bloom Filter**: 根据右表的值的行数来判断使用IN predicate还是Bloom Filter
+ - 默认在右表数据行数少于1024时会使用IN
predicate（可通过session变量中的`runtime_filter_max_in_num`调整）
+ - 否则使用Bloom filter
- **
Review comment:
是否可以给个最佳实践，引导用户使用。
1. IN/BF, 8
2. min max, 4
其他类型的runtime filter type，属于『高级用法』目录下。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@doris.apache.org
For additional commands, e-mail: commits-h...@doris.apache.org
