Cloudberry （三）布隆过滤器的 RuntimeFilter

CloudberryDB中的Runtime Filter。它实现了两种runtime filter方式。一种是：新增了RuntimeFilter算子，在Hash Join算子的探测端添加RuntimeFilter算子，当然这就导致仅在RuntimeFilter算子 bloom bitmap 实现提前过滤，并未将filter下沉到SeqScan算子或者TableAM层，仍旧存在不必要的算子计算。另一种是将runtime filter下推到SeqScan或者TableAM，尽量能够提前终止算子执行。后一种方式目前仅处于开发阶段，并未release，期待该功能尽快完善。

1、RuntimeFilter算子方式过滤

从上面执行几乎也可以看出，仅在Hash Join的探测端挂载了一个RuntimeFilter算子。首先看下该算子是怎么执行的。

1.1 结构体之间关系

主要关系是：HashJoin的运行时结构体HashJoinState的JoinState js即PlanState ps中有左右子节点的执行计划节点。左子树为探测端结构体RuntimeFilterState，执行运行时过滤的动作；右子树为HashState节点，rfstate为RuntimeFilterState地址。由此保证内表构建时，构建的bloom bitmap可以关联到探测端扫描外表时判断外表值是否在bloom bitmap中。

1.2 具体流程

1）MultiExecPrivateHash构建完hash表后，标记build_finish为true，确保RuntimeFilter节点执行时可以进入布隆过滤

2）MultiExecPrivateHash构建hash表时，调用ExecHashGetHashValue将内表值的join字段hash后放到bf中

3）ExecRuntimeFilter执行时，判断外表值是否在bf中，若在则将其输出，若不在则过滤掉，不进入join

4）可以看到，这种运行时过滤方式，仅将过滤下沉了一个执行节点，底层节点的扫描等多层执行计划节点并没有最优地避免执行，效果也不会太好。

2、filter下沉到SeqScan的方式

我们看下另一种实现方式，将布隆过滤下沉到SeqScan底层节点，这种方式比较彻底，可以尽最大可能减少不必要节点执行。

该patch可查看：

https://github.com/cloudberrydb/cloudberrydb/pull/405

Hash执行时构建布隆过滤器的流程如下图所示：