SQL wal_compression 的 WAL 压缩开启条件与 CPU/IO tradeoff

wal_compression 仅在 postgresql 10+、wal_level ≥ replica 且显式设为 on 或 pglz 时生效，仅压缩 full-page writes（fpw）记录，对普通 dml 无效；需 reload 生效，且受 full_page_writes=on 约束。

wal_compression 在 PostgreSQL 里到底开不开得成

开不了——除非你用的是 PostgreSQL 10+，且 wal_level ≥ replica（或 logical），同时 wal_compression 设为 on 或 pglz。低于这个组合，PostgreSQL 直接忽略该配置，日志照常不压缩。

常见错误现象：pg_stat_bgwriter 里 buffers_written 和 write_time 没明显变化，pg_waldump 查看 WAL 文件头也看不到压缩标记；或者明明配了 wal_compression = on，但 SHOW wal_compression 返回 off——大概率是 wal_level 还卡在 replica 以下，比如 replica 是最低门槛，minimal 就不支持。

• wal_level = minimal → wal_compression 完全无效，启动时也不报错，静默忽略
• wal_level = replica → 支持 wal_compression = on，但仅对 full-page writes（FPW）触发的 WAL 记录压缩，普通 DML 不压缩
• wal_level = logical → 同样只压缩 FPW，逻辑复制本身不带来额外压缩行为

压缩实际生效的 WAL 场景很窄

WAL 压缩不是“所有 WAL 都压”，它只作用于包含完整页面镜像（full page image）的 WAL 记录，也就是发生 checkpoint 后首次修改某页、或 page_checksums = on 时校验失败强制写 FPW 的情况。日常 INSERT/UPDATE/delete 产生的 WAL 记录，无论多大，一律不压缩。

所以如果你的 workload 是高频小事务 + 低 checkpoint 频率，wal_compression 几乎不产生效果；反之，如果 checkpoint_timeout 短（比如 5 分钟）、max_wal_size 小、或频繁执行 VACUUM FULL / CLUSTER，那 FPW 出现更频繁，压缩才有机会起作用。

• 判断是否真在压缩：查 pg_stat_bgwriter 的 stats_reset 时间后，对比 buffers_written 和 write_time 变化趋势，再用 pg_waldump -p $PGDATA/pg_wal/000000010000000000000001 | head -20 看 record header 是否含 compression: pglz
• FPW 触发条件受 full_page_writes 控制，必须为 on（默认），否则连 FPW 都不写，压缩自然无从谈起

CPU 和 IO 的 tradeoff 不是线性的，且取决于硬件瓶颈

开启 wal_compression 后，每次生成 FPW 都要多一次 CPU 压缩（pglz 算法），但写入磁盘的字节数可能减少 30%–60%。不过这个收益只在 IO 瓶颈明显时才体现出来：比如用 SATA SSD 或 HDD，WAL 写延迟高，减字节能直接降低 write_time；但如果用 NVMe，IO 延迟本身很低，CPU 压缩反而可能成为新瓶颈，尤其在高并发 checkpoint 场景下，bgwriter 和 checkpointer 进程 CPU 使用率会跳升。

• 不要假设“压缩=省 IO=更快”：在 CPU 密集型负载（如大量索引构建 + checkpoint）中，开启压缩可能让整体 TPS 下降 5%–10%
• wal_compression = pglz 是唯一选项（PostgreSQL 10–15），没有 LZ4/ZSTD 等替代；未来版本也未规划扩展算法
• 压缩发生在 WAL buffer 刷盘前，不改变 WAL 格式兼容性，备库无需额外配置即可解压回放

别漏掉 checksum 和 archive_command 的隐性影响

如果启用了 data_checksums = on，FPW 触发更频繁（因为 checksum mismatch 会强制写 FPW），这时 wal_compression 的触发概率上升，但同时也放大了 checksum 计算 + 压缩双重 CPU 开销。而如果还配了 archive_command，WAL 归档文件是压缩后的原始字节流，归档传输带宽下降，但恢复时需额外解压步骤——不过 PostgreSQL 自动处理，用户无感。

• pg_basebackup 备份出来的数据目录不含 WAL，所以不影响备份体积；但 pg_receivewal 接收的流式 WAL 是已压缩格式，本地存档大小会变小
• 使用 pg_dump / pg_restore 不涉及 WAL，和此配置完全无关
• 最易被忽略的一点：wal_compression 修改后必须 reload（pg_reload_conf() 或 kill -SIGHUP），不是改完就生效，而且只影响后续新生成的 WAL，旧 WAL 仍保持原样