在PolarDB中，"filter"的下推确实只能下推到Exchange和Join算子之下。这是因为PolarDB的设计目标是在保证查询性能的同时，尽量减少网络开销。在分布式数据库中，数据节点(Data Node, DN)负责存储数据，计算节点(Compute Node, CN)负责处理查询。当一个查询涉及多个表时，PolarDB会将这些表分发到不同的计算节点上进行处理。在这个过程中，PolarDB会将过滤条件(即Filter算子)下推到数据节点上，这样可以避免在计算节点之间传输大量不需要的数据，从而降低网络开销。
然而，PolarDB并没有实现将Filter下推到Aggregate(聚合)、Projection(投影)、Sorting(排序)或者Set Operations(集合操作)等算子之下。这是因为在这些算子中，Filter的下推可能会带来一些负面影响。例如，在一个大型表上进行聚合操作时，如果将过滤条件下推到每个数据节点上，可能会导致每个数据节点都需要处理大量的数据，从而增加计算负担。此外，在某些情况下，将过滤条件下推到这些算子之下可能会导致查询性能下降，因为这意味着更多的数据需要在计算节点之间传输。
总的来说，PolarDB的Filter下推主要是为了降低网络开销，提高查询性能。在设计和实现这个功能时，PolarDB的开发者们需要在保证查询性能和降低网络开销之间取得平衡。在这个过程中，他们可能会选择不去实现某些算子的下推，以便更好地满足PolarDB的设计目标。
