调优思路

Citus本身是一主多从的结构，Coordinator只负责协调分配任务，并不会处理实际的查询，Worker负责执行Coordinator分配的子查询任务，每个Worker本身就是一个完整的PostgreSQL环境，因此，提升Citus集群的性能就分为两部分：

1. 调优Coordinator制定执行计划的效率；
2. 调优各个Worker执行的效率，跟调优单节点PostgreSQL无异。

默认安装的PostgreSQL配置是比较保守的，如果你的机器硬件足够好，那么极有可能默认的配置并不能发挥所有的硬件性能。

基本原则

基本原则：边调优、边测试，也就是说，使用了某个调优手段后，最好马上使用Benchmark等工具测试数据库性能是否有提示。

任何时候，在不了解当前性能及其瓶颈的时候，最好不要谈优化，如果连当前的性能指标都不清楚，那么优化就变得没有意义，优化后，性能是否有提升，也需要验证，因此，使用benchmark工具及时了解当前数据库的性能指标是非常基础，也非常关键的。

推荐使用PostgreSQL自带的pgbench来进行测试，pgbench测试的是TPS-B（transaction per second），你既可以使用它默认的TPC-B，也可以自定义脚本测试。

默认安装的PostgreSQL，pgbench默认没有添加到系统的bin目录，所以我们执行pgbench，会报：

pgbench：command not found

我们需要做一个软链接：

ln /usr/pgsql-11/bin/pgbench /usr/bin/pgbench

从Citus集群执行逻辑层面优化

1、shard count

调整分片数量，所谓分片，就是子表，存储了整个表的一部分，citus会对一个查询中涉及到的所有分片进行并行查询，分片越多，并行的数量就越大，那么最终耗时就越少。在citus该设置是：“citus.shard_count”，默认32，我们可以适当调大，但也不是没有限制，每个查询都会建立一个连接来执行，不能超过PostgreSQL的最大连接数。

2、CTE与SubQuery

少写CTE查询，如果查询在节点间需要传输大量数据，那么最好考虑重新实现，这是citus不擅长的领域。如果必须要在节点间传输数据，最好将传输的数据量减少到最小，比如利用子查询过滤不必要传输的数据。

优化每个实际执行查询的Worker性能

参考

转载自：https://blog.csdn.net/qingyafan/article/details/87336115