能，clock_timestamp()差值可准确测量存储过程执行的墙上时间，需同事务内两次调用并妥善处理异常，避免用now()或statement_timestamp()，推荐结合日志表记录与性能视图分析。
clock_timestamp() 差值能准确测存储过程执行时间吗
能，但要注意它测的是「墙上时间」（wall-clock time），不是 CPU 时间，也不排除被系统调度暂停的影响。对绝大多数业务级耗时分析足够用，比如判断某个 UPDATE 是否突然变慢、函数是否受数据量增长拖累。
关键点在于：必须在同一次事务中调用两次 clock_timestamp()，且不能被异常中断或提前退出——否则结束时间拿不到，差值就失效。
在 PL/pgSQL 函数里正确记录起止时间
常见错误是把开始时间存在变量里，但没处理 EXCEPTION 块导致结束时间不被执行；或者误用 now()（它返回事务启动时刻，多次调用值不变）。
推荐写法：
CREATE OR REPLACE FUNCTION slow_query_demo() RETURNS void AS $$ DECLARE start_ts TIMESTAMPTZ; end_ts TIMESTAMPTZ; BEGIN start_ts := clock_timestamp(); <p>-- 这里放你要测的逻辑，比如： PERFORM pg_sleep(0.1); UPDATE accounts SET balance = balance + 1 WHERE id = 1;</p><p>end_ts := clock_timestamp(); RAISE NOTICE 'Execution took: % ms', EXTRACT(EPOCH FROM (end_ts - start_ts)) * 1000; END; $$ LANGUAGE plpgsql;
-
clock_timestamp()每次调用都实时获取系统时间，不受事务快照影响 - 用
EXTRACT(EPOCH FROM ...)转成秒再乘 1000，单位是毫秒，更直观 - 别用
timeofday()或statement_timestamp()替代——前者返回text需解析，后者在语句级重置，不适合跨语句测时
为什么不能直接在 CREATE FUNCTION 里用 \_RETURNING\_ 记录耗时
因为 RAISE NOTICE 是唯一能在函数运行中输出可观测日志的方式；想把耗时作为返回值，得改函数签名，比如返回 TABLE(elapsed_ms NUMERIC, result TEXT)，但这就改变了调用契约，下游 SQL 可能报错。
更实际的做法是：把耗时写进日志表，方便后续聚合分析：
INSERT INTO perf_log(func_name, elapsed_ms, run_at)
VALUES ('slow_query_demo',
ROUND(EXTRACT(EPOCH FROM (end_ts - start_ts)) * 1000, 2),
clock_timestamp());- 注意用
ROUND(..., 2)避免浮点精度干扰排序或分组 - 日志表建议加索引：
CREATE INDEX ON perf_log(run_at); - 如果函数可能被高频调用，避免每次
INSERT都触发 WAL 写入瓶颈，可考虑异步写入或批量缓冲
真实场景下容易被忽略的干扰项
测试结果偏高，不一定代表逻辑慢——可能是锁等待、WAL flush 延迟、或 shared_buffers 不足引发的磁盘读放大。
- 同一函数连续执行两次，耗时差异超过 20%，优先查
pg_locks和pg_stat_activity看是否有阻塞 -
clock_timestamp()本身开销极小（纳秒级），但频繁调用（如循环内）会叠加，此时应移出热点路径 - 在连接池（如 pgbouncer）下测时，要注意连接复用可能导致事务时间被意外拉长，建议在函数开头加
SET LOCAL statement_timeout = '5s';防止卡死
真正难的不是算差值，而是区分「代码执行耗时」和「数据库环境抖动」——得结合 pg_stat_statements 的 total_time 对照看。
