PostgreSQL 教程: 优化查询并行度

摘要：在本教程中，您将学习如何在 PostgreSQL 中提高每个查询的最大并行工作进程数。

目录

在过去几年里，PostgreSQL 的新版本在并行运行操作方面做得越来越好。

这对于分析型查询尤其有用，通过充分利用拥有大量处理器核心的大型服务器，这类查询的速度有时能大幅提升。

然而，对于快速的事务型查询，启动和管理进程的开销几乎总是不合算的。因此，PostgreSQL 的默认设置相对保守。

如果你认为你的工作负载能从更高的并行度中受益，那么非常值得去优化它。

第一个限制因素

你可能会遇到的第一个限制因素是 max_parallel_workers_per_gather 参数，其默认值仅为 2。

这意味着每个 Gather（或 Gather Merge）操作最多可以使用 2 个工作进程。如果没有修改过这个设置，你可能会在EXPLAIN计划中看到 “Workers Planned: 2” 和 “Workers Launched: 2”。请关注这些字段，将其作为查询可能受益于提高并行度的信号。

值得注意的是，这个限制和这些数字中不包括主导进程（leader process），所以默认情况下最多有 3 个进程。

测试和修改设置

你可以通过下面的命令查看当前的设置：

SHOW max_parallel_workers_per_gather;

你也可以通过运行一次查询，仅在当前会话中修改它，例如：

SET max_parallel_workers_per_gather = 4;

然后，你可以使用EXPLAIN查看，对于某个查询来说， PostgreSQL 是否认为使用额外的工作进程是个好主意。之后，你可以使用EXPLAIN ANALYZE查看它是否真的更快（以及快多少）。

同时，你绝对应该考虑的一些设置包括：

• work_mem – 每个工作进程都可以单独使用它
• max_parallel_workers – 系统级别的限制（默认值为 8）
• max_worker_processes – 一个更高的限制，包括后台作业（默认值为 8）

此外，如果并行化启动得太早或太晚，以下这些设置也需要了解：

• parallel_setup_cost
• parallel_tuple_cost
• min_parallel_table_scan_size
• min_parallel_index_scan_size

更多详细信息，请参考官方文档中的 “并行查询如何工作” 部分。

当你对测试结果满意，并希望全局修改设置时，可以在data/postgresql.conf文件中添加或修改它们，例如：

max_parallel_workers_per_gather = 4

如果你修改了max_worker_processes，需要重启数据库，否则，你需要通过重新加载配置来应用更改：

select pg_reload_conf();

或者从命令行执行：

pg_ctl reload -D /pgsql/data

较新的 PostgreSQL 版本逐渐改进了对并行化的支持，所以如果你使用的不是最新版本，值得测试一下升级。

但是，如果你的机器和工作负载需要非常高的并行度（大约 12 个以上的并行工作进程），在 PostgreSQL 上可能难以实现。

总结

如果你只在 PostgreSQL 上运行大量快速的事务型查询，可能根本不需要担心并行化。

然而，如果你要运行一些耗时较长的分析型查询，可以调整几个设置来加快查询速度，更好地利用服务器资源。

限制因素可能是max_parallel_workers_per_gather（其次是max_parallel_workers和max_worker_processes），但也有其他可以调整的设置。

了解更多

PostgreSQL 优化