針對最常見的內存錯誤OOM，需要說明(針對4.1之後版本，早起版本請前去查詢相關文檔)：
單語句的內存消耗受3個參數控制：gp_resqueue_memory_policy、statement_mem、max_statement_mem
A、缺省gp_resqueue_memory_policy配置爲eager_free，在此情況下，內存將物盡其用(我從詞面理解的，官方並未給出詳細說明)，但不能超過max_statement_mem的限制以及resource queue的memory_limit限制，此時如果resource queue未做限制(缺省資源隊列均無內存限制)，既存在OOM缺口，而此時statement_mem將不具備嚴格限制功能，同時max_statement_mem的缺省值爲2000MB。
B、當gp_resqueue_memory_policy配置爲auto時，內存消耗將受statement_mem和resourcequeue的memory_limit限制，同樣，缺省資源隊列無內存限制，不過，statement_mem的缺省值爲125MB。
綜合考慮內存限制參數，由於資源隊列的memory_limit缺省是沒有限制的，我們假設有10個需要消耗1000MB的語句同時提交。
對於A情況來說，需要向OS申請1000MB×10≈10GB的內存，這已經大於gp_vmem_protect_limit的缺省限制，此時，如果gp_vmem_protect_limit×節點節點實例數>>節點內存，則極有可能出現OOM錯誤，此時通過放大gp_vmem_protect_limit是可能帶來緩解的，但並非良措，因爲超過物理內存部分的內存申請需要SWAP來響應。而且，很容易超過物理內存+SWAP的總和，將繼續出現OOM且將進入無解狀態。
對於B情況來說，需要向OS申請125MB×10≈1.25GB<<10GB的內存，通常的硬件環境，每個Instance不至於少於2GB的內存。
如果按照gp_vmem_protect_limit缺省爲8192來計算，對於A情況，每個Instance需要向系統申請8GB內存，其餘的2GB需要pgsql_tmp目錄來響應。而對於B情況，每個Instance需要向系統申請2GB的內存，其餘的8GB需要pgsql_tmp目錄來響應。由於pgsql_tmp位於性能高於SWAP的數據盤(通常的環境是如此，不排除高福帥配置)，性能有一定保障，B情況通常不會出現OOM，且可承受的併發數遠大於A情況。
