带有过滤条件的hash join，首先针对左表构建hash表，然后对右表进行过滤，针对hash表中每个元组都对右表过滤后的结果进行探测，满足条件的作为join结果。当左表比较大时，构建hash表就需要较大代价。字节跳动的火山引擎Bytehouse中对hash join进行了优化。当右表过滤后结果集比较小时，将右表结果集作为过滤条件过滤左表，然后再构建hash表进行探测。如下图所示：
那就有问题了，虽然看起来这个idea可以带来较大收益，但需要思考是构建全量左表hash表的代价大还是提前过滤不会命中的join数据代价大呢？也就是什么场景下，什么阈值最好有个标量值下这种Runtime filter才具有优势呢？
Bytehouse中介绍，右表过滤后结果集比较小，同时左表非常大，但根据join条件过滤后结果集很小，这种场景下才适合启动Runtime Filter。
但是，还是上面问题，针对启用条件，bytehouse是否有变量阈值控制呢？这个就不得而知了。
