PostgreSQL 9.5中日期与字符串比对为何比日期与日期比对更快？

以下是导致该现象的核心原因：

• 统计信息估算偏差
  PostgreSQL查询规划器对**常量字面量（如'2023-04-18'）和stable函数（如current_date）**的处理逻辑不同。对于字面量，规划器可以直接用该值匹配表的统计数据，精准估算出符合created_at条件的行数（本次为32000行），进而选择更高效的分组策略——比如GroupAggregate，在内存内完成排序与分组，避免磁盘IO。

  而current_date属于stable函数，规划阶段无法确定其具体值（尽管它每天仅变化一次），只能依赖默认比例估算符合条件的行数。如果估算值远大于实际行数，规划器会错误选择HashAggregate：这种方式需要构建哈希表，若内存不足会触发磁盘交换，导致查询速度骤降。

• 隐式类型转换的额外开销
  如果你的查询条件是created_at::date = current_date，数据库需要对全表1200万条数据的created_at字段（假设为timestamp类型）逐行执行类型转换，再与current_date比较，这会显著增加CPU计算开销。

  而使用字面量字符串时，若采用范围查询写法created_at >= '2023-04-18' AND created_at < '2023-04-19'，数据库会直接将字符串隐式转为timestamp类型，与created_at原生类型直接比较，省去了逐行转换的成本。

• 执行计划缓存的适配问题
  若数据库开启了执行计划缓存，使用current_date的查询计划可能被缓存，但由于函数值的动态特性，缓存的计划未必适配当前数据分布；而字面量查询的计划是针对具体日期生成的，完全贴合实际数据情况，执行效率更高。

内容的提问来源于stack exchange，提问作者Henrique Capozzi