PostgreSQL 19性能提升看哪里？I/O、外键与COPY变化

19的性能改动分布在不同环节，不能视为统一加速按钮。大范围读盘、带外键写入和CSV装载遇到的限制不同，需要分别判断能否受益。

先查数据库实际慢在什么地方。时间若主要消耗在锁等待或网络上，即使某部分CPU计算更快，用户的整体响应也可能变化不明显。

一、I/O 工作进程：忙时增加，闲时减少

异步I/O已在18出现，19是在这个基础上继续优化。worker方式现在能随需求调节I/O工作进程数，不能把整套异步I/O说成19才新增。

简单说，读盘工作多了可以增加帮手，闲下来再减少。相关设置包括最少和最多工作进程、空闲退出时间，以及增加工作进程的间隔。

这组设置主要针对 io_method = worker。使用 io_uring 或 sync 时，不应照抄 worker 的调优建议。提高上限也不保证更快：磁盘已经很忙时，更多并发请求可能只是排更长的队。

适合重点测试的，是确实需要读大量数据的业务，例如大范围扫描和部分维护任务。小表已经全部在内存、查询主要消耗计算时，收益可能较小。

二、外键检查：写入业务可能受益

订单引用客户、明细引用订单，常常通过外键保证“引用的记录确实存在”。这种检查本身要做工作，写入很多记录时会累积成本。

19 改进了外键约束检查的执行效率。可能受益的，是外键检查占明显比例的写入流程；不能把某种测试里的加速比例直接套到所有 INSERT 上。

测试时应保留真实约束和典型写入组合。只对一张没有外键的空表做插入测试，无法说明这项优化是否帮助自己的业务。反过来，也不应为了追求导入速度先删掉外键，再用结果宣称约束检查更快。

还要观察锁等待、触发器、索引维护和提交耗时。若写入主要被这些部分拖住，外键检查更快也未必让整笔事务同比例缩短。

三、SIMD COPY：加快文本和 CSV 输入处理

SIMD 可以理解成 CPU 一次处理一批相似数据的办法。19 用它改进了 COPY FROM 的文本及 CSV 输入处理，批量装载这类文件时值得评估。

但导入还有读文件、传输、转换字段、写表、维护索引和生成 WAL 等步骤。文本解析只占其中一部分；如果磁盘写入已经是瓶颈，总导入时间就不会按解析速度的提升幅度缩短。

在 psql 中，可以使用客户端文件做测试。表结构和文件必须预先准备好：

这里的文件在运行 psql 的机器上。若使用服务端 COPY，则文件位置和权限要求不同。测试旧版与 19 时，要保持文件、表结构、索引、硬件和连接方式一致。

四、怎样做对比，才不会得出假结论？

每类测试重复多次，记录波动。不要把旧版本第一次读盘，与新版本已经预热后的结果直接比较。测试结束后，也要验证数据条数和业务约束，不能只看速度。

五、升级后变慢，别只怀疑新功能

升级后变慢时，先确认统计信息、计划、参数和缓存状态。部分长报表还可能受到JIT默认关闭的影响，应单独对比。

两个版本既要比较保留原设置的表现，也要记录针对新版本评估后的结果。一次改动很多参数，容易无法解释变化来自哪里。

三项改进都值得针对相应业务测试，但不能代替索引、SQL设计与维护。把现有瓶颈对应到具体能力，才能说明升级实际帮了什么。