PostgreSQL Parallel 并行 与 开源数据库

PostgreSQL 在的并行是从9.6开始的,到了目前的PostgreSQL 11 这个版本目前已经支持了partition-wise join, aggregates, 以及 Parallel Create Index 当然还是的提一下在PostgreSQL 10 已经支持的 Parallel Bitmap heap scan 和 Parallel Index Scan.

这里的顺便提一句，最近我为什么痴迷于PostgreSQL，还是经过本次贸易争端，发现如果把柄交在别人手里，自己总是不安心的，开源的东西可能用起来没有商业的东西有那么多后面的团队给你保护，但有保护又如何，2013年的工商银行系统瘫痪，不就是 某大型数据库及方案解决公司的问题（不敢提名字，谷歌都的赔他88亿），但等到类似于贸易战这样的时刻，人家给你一个漏洞，你整个国家的安全就岌岌可危了，放到企业也是一样，曾经这个公司的人员说，你买我一套数据库软件，就可以随便安装了，我倒是想问一句，这样的默许有法律保证吗，如果有法律保证，那还要法律部门干嘛，私下解决不就可以了吗。关键时刻人家还是要捅你刀子的，所以想省钱，又想有保证，那不就得自己努力自己研发，除此之外只能是在刀子上舔血，属于能活一天算一天的想法。

所以PostgreSQL 打出口号就是 开源界最好的数据库产品，这话其实不假，尤其面对传统企业（非互联网企业）。

PostgreSQL 在并行的处理上尤其到了 11 这个版本还是由点需要学习的，提升的性能。

我比较喜欢直接，不先来一些虚的，直接来看看PostgreSQL 怎么来打开并行。

先的从一些并行的参数说起

1 max_work_processes

这个设置是当前系统中支持的最大后台进程数，在slave库中这个设置还应该比主库的大一些，或一致。

2 max_parallel_workers

在查询中可以使用的最大的并行线程的数量

3 max_parallel_maintenance_workers

支持内建的过程使用并行的方式工作，例如建立索引，默认设置为2

4 max_parallel_workers_per_gather

支持并行的查询使用的线程数

其中的关系应该是 max_work_processes > max_parallel_workers > max_parallel_workers_per_gather >= max_parallel_maintenance_workers

另外设置完毕后，需要重新启动，这也就是说，在系统运行前就应该有一个相关的测试看看怎么设置比较好。

下面我们有一个1000万的行的表，我们看一下

并行到底和查询有什么关系

1 我们在两个PG 的服务器上，运行一个普通的查询，（无索引）

一个我们开了 4个 workers 一个我们开2个workers ，我们可以清晰的看出两个workers的数量不同造成的 cost的不同。

2 我们现在为这个表建立一个索引

我们做同样的测试，在建立索引的时候，我们分表测试 线程为 4 和 线程为 2 的方式，大家可以很清楚的第一个的创建时间要比第二个要快，第一个是4个线程，第二个是 2个线程

这说明适当的增加并行度，对数据库的操作是有性能提升的。

当然我们还的看看类似于简单的数据统计，如count 是否有明显的差异，我们可以看到，的确是有很大差异的。

到目前为止我想有的人可能会有其他的想法，就是我的并行度开的越多，越好，我们可以看看是这样的吗？

我现在将查询的并行度提高到8，然后在做比较，其妙的事情发生了，并行度为4 的查询比 并行度为8 的比较的查询速度还高。这说明一个情况就是并行度的增加未必是越多越好，与处事的道理一样，适合，恰当就好。

对比完这些事情，我们来看看到底 POSTGRESQL 在并行计算中的底层都做了点什么。

早期的postgresql 是对于查询的内存分配是 fixed的模式，而在有了并行度这个事情，则内存的分配就变得动态起来，由引导的进程和工作进程来组成并分配一块内存进行数据的处理。

这里的在说说那些应用还不支持并行，在11这个版本上

1 full out join 不支持并行

2 FDW 不支持并行

3 游标不支持并行（想想也是）

可能以后的进步方向

并行的排序， 更好的控制内存的利用，更多的有效的利用线程等等。

当然如果你使用了复制，则你要注意你的max_worker_processes 的设置 standby 与 primary的关系,否则 你就马上会很好看？