refactor: runtime filter

[xudong963]

I hereby agree to the terms of the CLA available at: https://databend.rs/dev/policies/cla/

Summary

Intro:
Adaptive derivation of new predicates at runtime is used to filter the join probe side to improve performance.

New predicates generated at runtime are pushed down through the processor to the table scan on the probe side for prune, thus improving performance significantly.

Simple benchmark
A simple example that is perfect for runtime filtering

select * from t1 join t2 on t1.a = t2.b;
t1: 1_000_000_000
t2: 9999 (inlist runtime filter will not be generated for >10k)

cluster:

before: 0.04 sec
runtime filter: 0.007 sec. 

single node:

before: 0.025s
runtime filter: 0.0046 s

Adaptive:

1. Currently only inlist filter is generated, and only if the total data size of the build is less than 10k. If the inlist is too heavy, it is not efficient, so we may consider supporting bloom filter for data larger than 10k in the future.
2. For clusters, only broadcast join supports runtime filter, because the data size gap between the build and probe sides of broadcast join is relatively large, and better filtering may be achieved.

Others:
Runtime filter will be saved into QueryCtx by HashMap, key is the table index, and values are filters for the table. Table will get the corresponding filters from ctx by table index to prune before it starts to read data.

• Closes #issue

---

This change is 

[github-actions]

Docker Image for PR

• tag: pr-13842-0b7053e

note: this image tag is only available for internal use,
please check the internal doc for more details.

[github-actions]

ClickBench Report

• hits: https://benchmark.databend.rs/clickbench/pr/13842/7097508519/hits.html
• tpch: https://benchmark.databend.rs/clickbench/pr/13842/7097508519/tpch.html

[Dousir9]

How to generate the test data of t1 and t2, is it numbers(1_000_000_000)?

[xudong963]

How to generate the test data of t1 and t2, is it numbers(1_000_000_000)?

yeah

[github-actions]

Docker Image for PR

• tag: pr-13842-faef3fd

note: this image tag is only available for internal use,
please check the internal doc for more details.

[github-actions]

Docker Image for PR

• tag: pr-13842-61e0906

note: this image tag is only available for internal use,
please check the internal doc for more details.

[github-actions]

ClickBench Report

• hits: https://benchmark.databend.rs/clickbench/pr/13842/7150353030/hits.html
• tpch: https://benchmark.databend.rs/clickbench/pr/13842/7150353030/tpch.html

[BohuTANG]

Do we need adding the runtime filter stats to explain? Now the stats:

├── pruning stats: [segments: <range pruning: 1 to 1>, blocks: <range pruning: 755 to 755, bloom pruning: 0 to 0>]

[xudong963]

current stats are collected before the pipeline runs, but runtime filter stats will be generated during the pipeline running. Maybe we can try to add runtime filter stats to query profile later.

[xudong963]

How about adding runtime_filter-related stats to the query log? @BohuTANG

[Dousir9]

rest LGTM !