一、前言

在一次對比oracle和greenplum查詢性能過程中，由於greenplum查詢性能不理想，因此進行定位分析，提升greenplum的查詢性能

二、環境信息

初始情況下，搭建一個小的集群，進行性能測試

PS:由於要求greenplum中的表數據類型和源表類型一直，且索引一致。所以所有欄位都為varchar類型且無索引，因此這方面沒有優化空間。

三、優化過程

3.1 結果對比

14.1S是不能接受的速度，因此需要查找原因，以期找出性能瓶頸，提供優化方案

3.2 分析過程

3.2.1 查看執行計劃

從①處可以看出，所有的耗時都在③的操作，seq scan上。

這裡①處的意思是（摘自官網）：

The numbers that are quoted by EXPLAIN are (left to right):

    Estimated start-up cost (time expended before the output scan can start, e.g., time to do the sorting in a sort node)

    Estimated total cost (if all rows are retrieved, though they might not be; e.g., a query with a LIMIT clause will stop short of paying the total cost of the Limit plan node's input node)

    Estimated number of rows output by this plan node (again, only if executed to completion)

    Estimated average width (in bytes) of rows output by this plan node

 ③處的意思是：順序掃描磁碟

從②處可以看出，所有的segment都參與了查詢

從④處可以看出，所有的列設置為varchar都進行了類型轉換，轉成了text，且沒有走索引（也無索引能用）

從⑤出可以看出，實際使用的記憶體遠小於分配的內容，所以這裡可以判斷出問題不在記憶體

3.2.2 查看數據分佈情況

這裡可以看到數據分佈是非常均勻的，所以不存在其中一臺計算節點耗時特別長的情況

3.2.3 查看CPU情況

既然記憶體沒有問題，那就可以嘗試看CPU和磁碟的使用情況了

在其中計算節點使用top命令查看：

這裡是其中一臺計算節點的截圖，這裡說明僅僅對於這一條SQL而言，已經消耗了CPU100%的資源，但是整機還有相當富餘的CPU資源可用

3.2.4 查看磁碟情況

使用sar命令查看計算節點情況

PS：這裡僅展示一套機器（實際情況中每一臺計算節點都是相同的情況）

這裡發現iowait一列是基本都為0，但是idle也為0，此處驗證了磁碟io沒有問題，問題出在CPU上

3.3 問題解決

前面說到這個greenplum集群建立的時候只在每台結算節點分配了一個segment，所以每台機器上只有一個CPU是忙碌狀態的，而其他的CPU處於空閑狀態

充分的利用CPU資源，就可以顯著提高查詢的性能。

因此，對這套集群的segment進行擴容，將原來的4個segment擴容為54個，並且重新建表後將所有varchar類型換成text，將參與查詢的日期列設置為分區鍵，分佈鍵不變，仍為id列

3.4 最終結果

 四、參考資料

https://www.postgresql.org/docs/9.2/static/using-explain.html