PostgreSQL 并行好不好，有人说好，有人说遭？

AustinDatabases 2025-05-16

186

❝
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共2800人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7群均已爆满，开8群300+ 9群 100+)

上个月，接了一个活，鸿门宴讲PostgreSQL -- 被拉去央企救场一天去给人家讲一下PostgreSQL的并行，本着给谁讲不是讲，他们花钱这里免费的原则。我总结了一下PostgreSQL并行的知识点。

PostgreSQL 并行

今天这么多的内容是写不完的，本期只针对SQL查询的部分进行内容的撰写和分析。随着主机的CPU核心的数量增多，对于SQL的并行的支持一直是各种商业数据库要考量的部分，作为开源的数据库PostgreSQL在SQL并行方面相对于其他的一些开源数据库是很良心的。

基于开源的POSTGRESQL数据库在QUERY并行参数的部分，给出了甚多的自由调整的参数，

参数	作用	建议
max_parallel_workers_per_gather	每个 Gather 节点最大并行 worker 数，默认 2	建议设为 CPU 核心数的一半或更高；大表可设为 4 - 8 以上 pgMustardCrunchy Data
max_parallel_workers	系统级并行 worker 总数，默认 8	应 ≥ max_parallel_workers_per_gather；不要超过 max_worker_processes PostgreSQL
max_worker_processes	后端总 worker 进程数，默认 8	留出给连接进程、维护任务等，避免配置过高导致系统负载 Database Administrators Stack Exchange
parallel_setup_cost	并行启动开销，默认 1000	可根据实际测试适当下调，让短查询也尝试并行 PostgreSQL
parallel_tuple_cost	元组传输开销，默认 0.1	若发现过多磁盘临时文件、I/O，可适当调高以减少无效并行 EDB
min_parallel_table_scan_size	并行顺序扫描阈值（表），默认 8MB	小表不并行；如业务表偏小，可酌情降低阈值 PostgreSQL
min_parallel_index_scan_size	并行索引扫描阈值（索引），默认 512KB	同上；索引扫描更轻量，可设置更低 PostgreSQL
parallel_leader_participation	是否让领导进程参与并行计算，默认 on	高 worker 数时可 off，让 leader 专注于收集合并 PostgreSQL
work_mem	单个 worker 的排序/哈希内存	并行时多个 worker 会并发申请，预留足够内存

说到这里，其实最让人困扰的是这些参数的关系，单独拿出一个参数都明白是什么意思，把这堆参数放一块，很多人就开始晕，咱们今天来去把这些参数之间的关系来梳理一下。

max_worker_processes，这个参数最容易被理解错误，这个参数主要的意义是限制除了你query session外的后台程序在POSTGRESQL中运行的数量，那么这些后台程序包含什么？

一句话和客户无关的后台进程都要收到这个参数的限制，那么到底那些进程受到他的限制：

1 并行的查询工作进程（由系统发起的并行） 2 逻辑复制进程 3 自动清理进程 4 后台维护进程

那么max_worker_processes 的意义何在这是我们应该对自己管理的数据库应该提出的问题，一句话解释，防止你滥用和其他参数配置错误，导致系统无法处理这些工作而最终资源耗尽而宕机。

举例比如你进来30个查询，每个查询都要触发进行并行操作，你并行操作设置的是4，也就是会产生 30 * 4 = 并行的查询的后台进程。

我们按照每个进程可以获得 8MB的内存 120 * 8 = 8160MB 的内存使用的量，此时如果你的系统仅仅就16G的内存，那么你这里设置 max_worker_processes 合适吗？显然是不合适的。

2 max_parallel_workers

这个参数是控制QUERY并行的时候到底可以产生多少个并行的works,这里就要考虑另一个问题，你要留下多少固定的processes 给非query的进程，一般情况下你要考虑你有没有逻辑复制，以及你的autovacuum的工作时的进程数是多少

max_parallel_workers = max_worker_processes - 固定的backgroud processes

具体多少，你就要看你的具体情况了，比如你有大量的逻辑复制，那么你这个部分就不能太多了，或者你系统的vacuum就是一个大问题，且你设置的autovacuum的工作进程数量较多，那么你也不能给max_parallel_workers 太多的数量，具体的情况就要具体的分析了，这也是和学生们要讨论和给出方案的部分。

那么如果设置不好会造成什么问题

1 查询挤压 2 内存耗尽系统OOM 3 逻辑复制挤压 4 autovacuum 无法分配进程导致dead tuple无法有效的被清理，系统性能下降。

而不足的max_parallel_workers，会导致并行查询无法获得足够的进程而无法进行并行查询。

3 max_parallel_workers_per_gather，这是今天要说的最后一个和查询有关的并行参数，这个参数是每个SQL可以使用的最大的并行度。

这三个参数是三级跳，max_worker_processes > max_parallel_workers > max_parallel_workers_per_gather

说到这里曾经有些同学认为 max_parallel_workers_per_gather 这个数量越大越好，他们认为更大的max_parallel_workers_per_gather 会然给一个SQL可以使用更多的CPU来处理一个SQL的数据，但在实际的应用中，

我们需要分清一些信息，三种典型的JOIN，并行是怎么进行应用的。

1 Hash join ,hash_join 的并行是从PG11引入的，并行的部分包含了构建hash表的工作，和后续的探查阶段的工作进程的数据量，从而加速hash join 的操作。

2 Merge_join，Merge_john 最大的需求是表和表之间的排序问题，通过对两个要进行john的表进行排序来进行比对，那么并行主要要用在表的排序中，通过在排序阶段加速来加快merge join的工作

3 Nested loop : 外表，内表，驱动表和被驱动表，或者称之为小表的大表，其实这也是一个数据的比对过程，而并行在这里进行使用的主要作用是通过对大表的并行扫描和小表的比对来加快数据的处理。

写到这里，为什么说并行太多会影响性能，我们想一个问题，并行的资源来自于数据索取后的归并，那么归并分为有序归并和无序归并，有序的归并消耗会更多，这里每个tumple在 gather merge的时候都要消耗，越多的 works并行，就会导致越多的CPU消耗，且长时间霸占，这样会导致其他的查询无法获得有效的并行，所以在有序需求场景多的地方，合理配置并行查询参数是一门功课！

如果这篇文章对您有帮助，且不麻烦的话，谢谢帮我投一票，二维码或连接进入，给Austindatabases 投上您宝贵的 10票（一次可以投10票），不胜欣喜，您的支持是我最大的动力。

https://zt.itpub.net/topic/peanit/