优化 COPY FROM PROGRAM 导入性能需减少 fork 开销、提升 I/O 吞吐、避免隐式转换，并利用并行解析；推荐用持久化进程、进程替换或 libpq 流式接口替代频繁 shell 调用。
使用 COPY FROM PROGRAM 通过管道导入数据时，性能瓶颈往往不在 SQL 本身，而在外部命令的启动开销、数据流缓冲、编码转换和系统资源调度上。优化关键在于减少进程创建次数、提升 I/O 吞吐、避免隐式转换，并让 PostgreSQL 充分利用其并行解析能力。
用持久化子进程替代反复 fork
每次执行 COPY FROM PROGRAM 'cat file.csv'，PostgreSQL 都会为每条 COPY 命令 fork 一个新 shell 进程——即使只是读一个文件。高频调用时，fork+exec 开销显著。更优做法是用长生命周期进程持续输出，例如：
- 用
stdbuf -oL控制行缓冲，配合tail -f /tmp/data.fifo或命名管道（FIFO），让外部程序“流式喂入”数据 - 用 Python/Go 编写轻量导出服务，监听 socket 或 stdin，复用连接与内存，避免每次重新加载数据或初始化上下文
- 对压缩文件，优先用
zcat -c data.csv.gz | psql -c "COPY t FROM STDIN WITH (FORMAT csv)"，而非COPY FROM PROGRAM 'zcat data.csv.gz'，前者由 shell 管道统一调度，后者每次触发独立 zcat 实例
调整 COPY 参数匹配数据特征
默认参数面向通用场景，但 CSV 导入可针对性调优：
- 显式指定
DELIMITER、QUOTE、NULL，避免 PostgreSQL 自动探测；若字段无引号、无空值，加FORCE_NOT_NULL和ENCODING 'UTF8'可跳过字符合法性检查 - 批量提交时，禁用
FREEZE（除非确定事务后不更新），并确保目标表已关闭autovacuum（临时）以减少后台干扰 - 对超大导入，配合
SET synchronous_commit = off和SET wal_level = replica（仅限可信环境），降低 WAL 写入等待
绕过 shell 解析，直连标准输入
COPY FROM PROGRAM 本质是调用 system() 执行 shell 命令，引入额外解析层。更高效路径是绕过它：
- 用
psql -c "COPY t FROM STDIN ..." < <(your_command)，即进程替换（bash/zsh），数据直接经 pipe 传入，无 shell 字符串解析与 fork 开销 - 在应用层用 libpq 的
PQputCopyData+PQendcopy接口流式推送，完全规避 SQL 层的 PROGRAM 调度逻辑，吞吐量可提升 2–5 倍 - 若必须用 SQL，改用
COPY FROM '/path/to/file'（需 superuser + 文件在数据库服务器本地），比 PROGRAM 快一个数量级——前提是文件可预置且权限可控
监控与定位真实瓶颈
别只看“导入慢”，先确认卡在哪一环：
- 用
strace -p $(pgrep postgres) -e trace=clone,execve,read,write观察是否频繁 clone/exec；若 clone 调用远多于 write，说明进程启动是主因 - 查
pg_stat_progress_copy视图，关注bytes_processed增速与total_bytes比值，若长期停滞在低百分比，大概率是源命令未及时输出或阻塞在 IO - 对比
time your_command | wc -l和time psql -c "COPY ..."耗时，拆分出数据生成、传输、解析三阶段耗时，再逐项优化
