PostgreSQL - PostgreSQL/PostGIS 性能调优

1、优化资源占用

无法对服务器环境预估，所以PostgreSQL配置中参数都比较保守，不是对服务器资源量身定制，都默认是最小。其中两个参数，根据服务器实际资源情况调整会对性能影响很大：

• shared_buffers，缓存查询过程中的临时数据，内存的1/4比较合适，默认128M；
• work_mem，sort和hash表操作需要占用的内存，不够用时，会向磁盘中写文件，磁盘的性能和内存相差可不少，默认4M；

2、频繁改动的表要周期性执行analyze

简单来说，PostgreSQL的query planner依赖统计查询所涉及的表的统计信息来做执行计划，如果统计信息不及时，那么执行计划可能并不是最高效的，甚至非常低效。执行analyze，可以更新指定表的统计信息，因此好的实践是按照一定规则的自动执行analyze。PostgreSQL提供了“autovacuum_analyze_threshold”参数和“autovacuum_analyze_scale_factor”参数，“autovacuum_analyze_threshold”设定对表执行update或insert影响到的行数，如果超过这个值，就会触发analyze；“autovacuum_analyze_scale_factor”设定如果表增加的体积超过指定的比例，则触发analyze操作。

根据你的数据实际情况和需求确定这两个值吧。

3、索引是不能少的

在图书馆里找一本书，如果没有各个书柜上的索引分类，在书海中抄到一本书。。也不是不可能，最好情况，你走运，看到的第一本就是，不走运时，翻遍了整个图书馆的几千万？本书，最后一本是你想要的书。平均情况，你找一本书也得用个几个月吧。所以，数据库的索引和图书馆的图书索引作用是一样的，原理也类似。

在任何的数据库中，建立索引都能极大的提升查询的性能，在Citus集群中也不例外。

在有可能查询在运行的表中创建索引，要注意添加上”concurrently“，这样不会对表上锁，不会阻止写操作。添加”concurrently“不会影响创建索引的性能。

4、explain && explain analyze

你以为的以为不是PostgreSQL Query Planer以为的以为，要分析一个查询的执行计划，进行优化，就得知道PostgreSQL是怎么计划的，使用explain可以查看执行计划。

优化查询时，explain和explain analyze是非常有用的工具，通过explain可以查看PostgreSQL的执行计划，explain和explain analyze不同之处在于explain不会真正执行查询，执行计划中的耗时是估计值，且并不是以毫秒为单位，而explain analyze会真正执行的查询，其执行计划中的耗时也是比较准确的数值，且耗时单位是毫秒。需要注意的一点是，explain analyze报告的最终执行耗时往往包含explain analyze自身的耗时，一般能占到查询耗时的30%，实际使用中，一个执行6分钟的查询，实测多占用时间甚至达到了50%。

所以使用explain analyze总耗时并不是真正查询耗时，其结果主要用于参考哪个过程耗时较长，可以优化。

5、连接池

pgbouncer vs pgpool-II

6、远离update

update不支持并行，一条一条更新，数据量大了，岂不是会等到天荒地老？

7、允许并行，根据你的硬件调整并行参数

“max_parallel_worker”

8、测试你的成果

sysbench