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