資料距離cpu越近效率越高，而離cpu由近到遠的主要裝置有暫存器、cpu cache、ram、disk drives等。cpu的暫存器和cache是沒辦法直接優化的，為了避免磁碟訪問，只能盡可能將更多有用資訊存放在ram中。greenplum資料庫的ram主要用於存放如下資訊。
因此最大化地保持資料庫資訊在記憶體中而不影響其他區域才是最佳的調優方式，但這常常不是一件容易的事情。
postgresql並非直接在磁碟上進行資料修改，而是將資料讀入shared buffercache,進而postgresql後台程序修改cache中的資料塊，最終再寫回磁碟。後台程序如果在cache中找到相關資料，則直接進行操作，如果沒找到，則需要從kernel disk buffer cache 或者磁碟中讀入。postgresql 預設的shared buffer較小，因為記憶體不僅僅用於shared buffer cache。剛開始可以設定乙個較小的值，比如總記憶體的15%，然後逐漸增加，過程中監控效能提公升和swap的情況。
設定優化器假設磁碟快取記憶體的大小用於查詢語句的執行計畫判斷，主要用於判斷使用索引的成本，此引數越大越有機會選擇索引掃瞄，越小越傾向於選擇順序掃瞄，此引數只會影響執行計畫的選擇。
當postgresql對大表進行排序時，資料庫會按照此引數指定大小進行分片排序，將中間結果存放在臨時檔案中，
這些中間結果的臨時檔案最終會再次合併排序，所以增加此引數可以減少臨時檔案個數進而提公升排序效率。當然如果設定過大，會導致swap的發生，所以設定此引數時仍然需要謹慎。同樣剛開始仍可以設定為總記憶體的5%。
temp_buffers即臨時緩衝區，用於資料庫訪問臨時表資料，greenplum預設值為1m。可以在單獨的session中對該引數進行設定，在訪問比較大的臨時表時，對效能提公升有很大幫助。
設定客戶端字符集，預設和資料庫encoding相同。
控制傳送至客戶端的資訊級別，每個級別包含更低階別的訊息，越是低的訊息級別傳送至客戶端的資訊越少。例如，warning級包括warning、error、fatal、panic等級別的資訊，而panic則只包括panic級別的資訊。此引數主要用於錯誤除錯。
設定執行計畫評估每乙個索引行掃瞄的cpu成本。同類引數還包括cpu_operator_cost、cpu_tuple_cost、cursor_tuple_fraction。
設定伺服器中postgres程序可用的總記憶體，建議設定為(x*physical_memory)/primary_segments,其中x可設定為1.0和1.5之間的數字，當x=1.5時容易引發swap，但是會減少因記憶體不足而失敗的查詢數。
檢視資料是否有傾斜
select gp_segment_id, count(*) from registration_record group by 1 ;
配置greenplum引數
在進行乙個greenplum安裝之前需要進行配置一下相關的系統引數,否則很容易出現意想不到的錯誤.1.修改系統引數 編輯 etc sysctl.conf 以下是最小配置 kernel.shmmax 500000000 kernel.shmmni 4096 kernel.shmall 40000000...
Greenplum介紹 配置系統和引數
關於gp master引數和本地引數 伺服器配置檔案 postgresql.conf 和postgresql一致 在gp中master和所有segment都有自己的postgresql。conf檔案。master parameters 僅僅在master instance上設定，查詢時候這些值被傳遞...
Django cms show menu引數解釋
當頁面結構設定 admin cms page 如下 home level 0 about us level 1 about company services level 2 foo bar level 3 our management team level 2 some other section ...