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 仍保持原样
