所谓谓词下推，就是将尽可能多的判断更贴近数据源，以使查询时能跳过无关的数据。用在SQL优化上来说，就是先过滤再做聚合等操作。
要理解谓词下推，应该从两个方面来看，即谓词和下推两部分。
1.什么是谓词
predicate push down 翻译为谓词下推，这个翻译很准确，明确的告诉了我们这个操作是一个什么动作，但是为人诟病的是，什么是谓词，结合起来是什么意思，就比较难以理解。
predicate（谓词）即条件表达式，在SQL中，谓词就是返回boolean值即true和false的函数，或是隐式转换为bool的函数。SQL中的谓词主要有 LKIE、BETWEEN、IS NULL、IS NOT NULL、IN、EXISTS其结果为布尔值，即true或false。
ps:并非所有谓词都可以在HAVING子句中使用。
这样是不是就可以很好的理解了什么是谓词。
2.什么是下推
下是table_A和table_B，即数据源头。
上是Result，即数据结果。
3.什么是谓词下推
看到这里，我们可能已经理解了什么是谓词下推，基本的意思predicate pushdown 是将SQL语句中的部分语句( predicates 谓词部分 可以被 “pushed” 下推到数据源或者靠近数据源的部分。
在Hive SQL和Spark SQL等一系列SQL ON Hadoop的解析语法树时都在谓词下推方面作出了优化，其实在使用SQL的过程，我们心中记住这是一种将过滤尽可能在靠近数据源（取数据）的时候完成的一种操作，是数据库的一种经典的优化手段。
4.一些常见的应用
4.1传统数据库应用
在传统数据库的查询系统中谓词下推作为优化手段很早就出现了，谓词下推的目的就是通过将一些过滤条件尽可能的在最底层执行可以减少每一层交互的数据量，从而提升性能。
select count(0 from A Join B on A.id = B.id
where A.a > 10 and B.b < 100;通过查看执行计划，可以看到，在处理Join操作之前需要首先对A和B执行TableScan操作，然后再进行Join，再执行过滤，最后计算聚合函数返回，但是如果把过滤条件和分别移到A表的TableScan和B表的TableScan的时候执行，可以大大降低Join操作的输入数据。
select count(0 from (select * from A where a>10 A1
Join (
select * from B where b<100
B1 on A1.id = B1.id;4.2Hive中的谓词下推
下面说说Hive中的谓词下推（同样适用于SparkSQL）
具体配置项是，默认为true，即开启谓词下推。
规则的逻辑描述如下：
During Join predicates cannot be pushed past Preserved Row tables（ join条件过滤不能下推到保留行表中）
select s1.key, s2.key from src s1 left join src s2 on s1.key > '2';而s2表不是保留行，所以s2.key>2条件可以下推到s2表中：
select s1.key, s2.key from src s1 left join src s2 on s2.key > '2';After Join predicates cannot be pushed past Null Supplying tables（where条件过滤不能下推到NULL补充表）
select s1.key, s2.key from src s1 left join src s2 where s1.key > '2';而以下选择由于s2未NULL补充表所以s2.key>2过滤条件不能下推
select s1.key, s2.key from src s1 left join src s2 where s2.key > '2';关于join和where，PPD采用的规则如下：
对于Join(Inner Join、Full outer Join，条件写在on后面，还是where后面，性能上面没有区别；
对于Right outer Join，左侧的表写在on后面、右侧的表写在where后面，性能上有提高；
所谓下推，即谓词过滤在map端执行；所谓不下推，即谓词过滤在reduce端执行
select a.* from a join b on a.id = b.id
where a.ds = '2022-08-15' and a.create_time = unix_timestamp(;因为是不确定函数，在编译的时候无法得知，所以，整个表达式不会被pushed，即也不会被提前过滤。类似的不确定函数还有等。
4.3列式存储中的谓词下推
以Parquet为例，优化的方法是对每一个Row Group的每一个Column Chunk在存储的时候都计算对应的统计信息，包括该Column Chunk的最大值、最小值和空值个数。通过这些统计值和该列的过滤条件可以判断该Row Group是否需要扫描。另外Parquet未来还会增加诸如Bloom Filter和Index等优化数据，更加有效的完成谓词下推。
ORC File也是类似的操作，具体在讲解ORC File时详细说明。
这个过程如下：
在存储层即过滤了大量大表无效数据，减少扫描无效数据列的同行其他列数据IO
减少存储进程到计算进程传输的数据
减少hashjoin开销
例如如下sql:
select item.name, order.* from order , item where order.item_id = item.id and item.category = ‘book’使用谓词下推，会将表达式下推到join条件之前。