PostgreSQL中内置AGE函数为何比整数减法执行速度慢？

测试的两种实现写法 #

年份直接做差实现 #

SELECT
    date_part('year', NOW())::integer - date_part('year', birth_date)::integer
FROM data_table;

内置AGE函数实现 #

SELECT
    date_part('year', AGE(birth_date))::integer
FROM data_table;

经3次重复压测，第一种写法比第二种写法快2-3秒，和「内置函数性能更高」的直觉不符，核心原因如下：

• 首先不存在「内置函数一定比手写运算快」的绝对结论：多数内置函数为了覆盖全场景的通用需求，会内置大量边界校验、特殊场景处理逻辑，这部分通用逻辑带来的额外开销，在特定简单业务场景下反而会成为性能负担。
• 两种写法的运算链路长度差距极大：
  • 第一种年份做差的写法，执行链路只有3步：调用2次date_part分别取当前年份、出生年份的整数值，做1次整数减法返回结果，全程没有复杂的日期运算，没有额外的类型构造开销。在默认人员在世、不需要严格校验当年生日是否已过的场景下，这个逻辑完全匹配需求，没有冗余操作。
  • AGE()函数是通用的时间差计算函数，单参调用时默认计算从入参时间到当前时间的完整间隔，底层执行步骤远多于简单取年做差：
    1. 首先做入参类型校验、时区对齐处理，兼容timestamp、timestamptz、date等多种入参类型
    2. 按年、月、日的顺序逐位计算差值，还要处理日期借位逻辑：比如当前日期是10月1日，出生日期是12月1日，计算时要在年份差的基础上减1，因为当年生日还没到，这一步需要额外对比月、日的数值，处理大小月、闰月等特殊日期场景
    3. 将计算得到的年、月、日差值组装为interval复合类型返回，外层的date_part再从这个复合类型中提取年份字段做整数转换
• 大表批量计算时，AGE()多出来的类型校验、借位运算、interval类型构造和拆解的开销会被逐行累计，最终就会体现为数秒的性能差距。

补充提示：第一种年份直接做差的写法没有处理「当年生日未到需减1岁」的逻辑，如果业务要求严格的法定周岁计算，直接使用会出现结果误差，不能仅为了性能盲目替换；如果业务场景已经提前确认不需要这部分校验，第一种写法确实是性能更优的选择。

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