now()作为函数参数的求值机制及分区表全扫描问题咨询

嘿，这俩问题都是PostgreSQL里经常碰到的典型场景，我给你掰扯清楚：

问题1：now()作为函数参数时的求值逻辑 #

首先得明确：now()在PostgreSQL里是STABLE类型的函数——意思是在同一个事务内，它的返回值是固定不变的。当你把now()作为参数传入函数时，它的求值时机是在函数开始执行之前，而不是函数内部每次用到这个参数的时候才计算。

举个直观的例子，假设你有这样一个测试函数：

CREATE OR REPLACE FUNCTION test_now(param timestamptz)
RETURNS timestamptz AS $$
BEGIN
    PERFORM pg_sleep(5); -- 让函数暂停5秒
    RETURN param;
END;
$$ LANGUAGE plpgsql;

当你调用SELECT test_now(now());时，now()会在函数开始执行前就计算出当前时间，哪怕函数内部睡了5秒，返回的还是调用函数那一刻的时间，绝对不会是5秒后的时间。

对比一下，如果是clock_timestamp()这种VOLATILE类型的函数（事务内返回值会变化），作为参数传入时同样是在函数执行前求值，但它本身的特性决定了如果在函数内部直接调用，返回值会随时间变化——不过now()本身是STABLE，所以不用担心这个问题。

问题2：分区表使用now() - interval导致全分区扫描的解决方法 #

你说的这个情况太戳痛点了！核心原因就是PostgreSQL的查询规划器在生成执行计划时，没法预知now()在执行阶段的具体值（虽然now()是STABLE，但规划时它还是个“不确定的变量”），所以不敢贸然跳过任何分区，只能生成全扫描的计划。

不过不用慌，有几个靠谱的解决办法：

• 方法1：在应用层预先计算时间常量
  这是最简单直接的方案。比如在你的应用代码里，先算出当前时间 - 72小时的具体时间值（比如2024-05-20 14:30:00+08），然后把这个常量值写入SQL语句：

  SELECT * FROM your_partitioned_table 
  WHERE reading_time > '2024-05-20 14:30:00+08'::timestamptz;
  

  这样规划器能明确看到时间范围，直接修剪掉不符合条件的分区，完美发挥分区表的优势。

• 方法2：用PL/pgSQL动态生成查询（适合数据库内部执行）
  如果你的查询是在数据库函数里执行，可以先把时间值计算出来，再用动态SQL构建查询——动态SQL里的时间是常量，规划器能正常做分区修剪：

  CREATE OR REPLACE FUNCTION get_recent_readings()
  RETURNS SETOF your_partitioned_table AS $$
  DECLARE
      cutoff_timestamptz timestamptz := now() - '72:00:00'::interval;
  BEGIN
      RETURN QUERY EXECUTE format(
          'SELECT * FROM your_partitioned_table WHERE reading_time > %L',
          cutoff_timestamptz
      );
  END;
  $$ LANGUAGE plpgsql STABLE;
  

  调用这个函数时，实际执行的SQL里是具体的时间值，分区修剪就能正常工作。

• 方法3：利用PostgreSQL 12+的运行时分区修剪
  如果你用的是PostgreSQL 12或更高版本，默认开启了enable_partition_pruning参数（可以用SHOW enable_partition_pruning;确认），那即使规划器生成的是全分区扫描的计划，执行阶段会根据now()的实际值自动修剪掉不符合条件的分区。
  你可以用EXPLAIN ANALYZE来验证：执行EXPLAIN ANALYZE SELECT * FROM your_partitioned_table WHERE reading_time > (now() - '72:00:00'::interval);，查看输出里的Actual partitions scanned部分，会发现实际只扫描了符合条件的分区，而不是所有分区。这个方法不需要改代码，适合不想调整应用逻辑的场景。

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