最近对 pg_dump 的速度很感兴趣。具体来说，这些年来它有没有变快？如果变快了，具体是多少？
几年前，我遇到过需要运行 pg_dump 的情况，当时发现了一些效率低下的问题，后来修复了。当时大概是版本 12 左右。那么，现在情况怎么样？有趣的是，情况不太好……
因此，为了测试它，我安装了从 10 到 18 的所有版本。版本 10 到 17 取自 pgdg apt repo，版本 18 于 4 月 30 日从 git HEAD 编译。
为了确保转储速度取决于 pg_dump 本身，我制作了没有数据但对象数量相当多的测试数据库：pg_class 中有超过 240 万个关系，其中 288k 个是表，170 万个是索引。
该数据库是我过去几年一直在使用的生产数据库之一的模式副本。
为了确保测试了所有可能的情况，我进行了 5 种类型的转储：
- pg_dump -Fp -s
- pg_dump -Fc -s
- pg_dump -Fc -s -ZX – 其中 X 为6（对于 PostgreSQL 15 及更早版本），对于较新版本， X 为 gzip:6
- pg_dump -Fd -j8 -s
- pg_dump -Fd -j8 -s -ZX – 其中 X 具有与上面相同的值
这些转储都连续运行了三次，我选择了最快的结果。
首先要说的是，pg_dump 选项并没有改变任何实际操作。这说得通——并行化（使用-Fd -j… 选项）有助于数据转储，但我当时只是转储了模式，而且模式本身是单进程的。
在所有 9 个版本中，pg_dump 选项之间的最大差异为 1.7%。因此，为了避免数据过载，我们仅关注每个版本的单个值，例如pg_dump -Fp -s：
| 版本 | 时间 | 改进 | 最快的百分比 | 查询数量 |
|---|---|---|---|---|
| 10 | 63.743秒 | — | 302.1% | 3270 |
| 11 | 55.259秒 | -13.3% | 261.9% | 3270 |
| 12 | 54.861秒 | -0.7% | 260.0% | 3271 |
| 13 | 54.980秒 | +0.2% | 260.6% | 3271 |
| 14 | 45.287秒 | -17.6% | 214.6% | 3271 |
| 15 | 21.410秒 | -52.7% | 101.5% | 829 |
| 16 | 21.099秒 | -1.5% | 100.0% | 371 |
| 17 | 29.049秒 | +37.7％ | 137.7% | 372 |
| 18 | 31.605秒 | +8.8% | 149.8% | 79 |
嗯，这跟我预想的不太一样。首先，它似乎比我预期的要快得多。这当然是好事。但糟糕的是，v17 和 v18 似乎带来了一些速度上的下降。
请注意，我运行了 5 个不同的 pg_dump 选项组合，每个组合运行了 3 次。因此，每个版本的 pg_dump 我都运行了 15 次。这样应该可以消除任何“随机负载波动”的可能性。
版本 15 和 16 的加速似乎与发送到服务器的查询数量的显著减少直接相关。但是为什么版本 17 和 18 反而更慢呢？
当然，我们必须明白，我的测试是在最坏的情况下进行的。表格数量非常多，却没有数据。不过，看到其中的差异还是很有趣的……
原文地址：https://www.depesz.com/2025/05/22/pg_dump-speed-across-versions/
