一、PostgreSQL基本參數優化：
PostgreSQL的配置文件是數據庫目錄(/opt/PostgresPlus/8.3/data)下的 postgresql.conf文件， 8.0以后的版本可支持K，M，G這樣的參數，只要修改相應 參數后重新啟動PostgreSQL服務就OK了。
shared_buffers：這是最重要的參數，postgresql通過shared_buffers和內核 和磁盤打交道，因此應該盡量大，讓更多的數據緩存在shared_buffers中。通常設 置為實際RAM的10％是合理的，比如50000(400M)
work_mem： EnterpriseDB在執行排序操作時，會根據work_mem的大小決定是 否將一個大的結果集拆分為幾個小的和 work_mem查不多大小的臨時文件。顯然拆 分的結果是降低了排序的速度。因此增加work_mem有助於提高排序的速度。通常設 置為實際RAM的2% -4%，根據需要排序結果集的大小而定，比如81920(80M)
effective_cache_size：是PostgreSQL能夠使用的最大緩存，這個數字對 於獨立的PostgreSQL服務器而言應該足夠大，比如4G的內存，可以設置為3.5G (437500)
maintence_work_mem：這里定義的內存只是在CREATE INDEX, VACUUM等時用 到，因此用到的頻率不高，但是往往這些指令消耗比較多的資源，因此應該盡快讓 這些指令快速執行完畢：給 maintence_work_mem大的內存，比如512M(52428
max_connections： 通常，max_connections的目的是防止max_connections * work_mem超出了實際內存大小。比如，如果將work_mem設置為實際內存的2%大小， 則在極端情況下，如果有50個查詢都有排序要求，而且都使用2％的內存，則會導 致swap的產生，系統性能就會大大降低。當然，如果有4G的內存，同時出現50個如 此大的查詢的幾率應該是很小的。不過，要清楚 max_connections和work_mem的關系。
二、EnterpriseDB Postgres Plus Advanced Server優化
在EnterpriseDB上有DynaTune的功能可以實現系統自動的優化，EDB提供了系統優化的最簡易步驟：
修改/opt/PostgresPlus/8.3/data/postgresql.conf
將edb_dynatune設為100：讓系統自動設置，本服務器為數據庫專用服務器，盡可能使用系統資源，並對當前數據庫的常用操作進行分析優化
將edb_dynatune_profile設為oltp：讓系統自動設置，本服務器用於處理OLTP高並發事務處理，以此標准進行優化
設置這兩項后重啟edb_8.3服務
三、數據庫系統啟動后可以通過以下方式查詢當前系統參數的設置情況：
edb# select * from pg_settings;
特別是在EnterpriseDB使用了DynaTune功能后，可以通過以上查詢查看系統自動進行調整后的參數值
四、增加最大連接數到2000以上
Linux操作系統中默認的SEMMNI一般只能支持2000個左右的連接，這個值應該設為 max_connections*16，但實際上各不同的系統中有似乎有一點偏差，如：
SEMMNI=128時，公式算出的最大連接數(max_connections)為2048，在RHEL5中最大 只能用到2030
RHEL5中修改SEMMNI方法：
在文件/etc/sysctl.conf中加入一行
kernel.sem=250 32000 32 128
當中最后一個“128”為當前的SEMMNI
執行
sysctl -p使操作系統當前的sysctl設置生效
對於任何數據庫軟件，內存配置項都是很重要的配置項。在 PostgreSQL 主要有以下幾個內存配置參數。
shared_buffers: integer 類型，設置數據庫服務器將使用的共享內存緩沖區數量，此緩沖區為緩沖數據塊所用。此緩沖區是放在共享內存中的。每個緩沖區大小的典型值是 8K 字節，默認值通常是 4000，對於 8KB 的數據塊則共享內存緩沖區大小為 400*8KB=32MB。這個數值必須大於 16，並且至少是 max_connections 數值的兩倍。通常都會把此值設置的大一些，這樣可以改進性能。一般設置為物理內存的 25%，若把 shared_buffers 設置的更大，如超過物理內存的 40%，就會發現緩沖的效果並不明顯了，這是因為 PostgreSQL 是運行文件系統之上的，若文件系統也有緩存，將導致雙緩存過多，造成負面影響。
temp_buffers: integer 類型，設置每個數據庫會話使用的臨時緩沖區的最大數目。此本地緩沖區只用於訪問臨時表。臨時緩沖區是在某個連接會話的服務進程中分配的，屬於本地內存。臨時緩沖區的大小也是按數據塊大小分配的，默認是 1000，對於 8K 的數據塊大小為 8MB。
work_mem: integer 類型，聲明內部排序操作和 Hash 表在開始使用臨時磁盤文件之前可使用的內存數目。這個內存也是本地內存，默認是 1MB。請注意對於復雜的查詢，可能會同時並發運行好幾個排序或散列（hash）操作；每個排序或散列操作都會分配這個參數聲明的內存來存儲中間數據，只有存不下才會使用臨時文件。同樣，好幾個正在運行的會話可能會同時進行排序操作，因此使用的總內存量可能是 work_mem 的好幾倍。 ORDER BY、DISTINCT 和 MERGE JOINS 都要用到排序操作。Hash 表在以 Hash join、Hash 為基礎的聚集、以 Hash 為基礎的 IN 子查詢處理中都要用到。
maintenance_work_mem: integer 類型，聲明在維護性操作（比如 CACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等）中使用的最大內存數。默認是 16 MB。在一個數據庫會話里，只有一個這樣的操作可以執行行，並且一個數據庫實例通常不會有太多這樣的工作並發執行，把這個數值設置得比 work_mem 大一些通常是合適的。更大的設置可以提高上述操作的速度。
max_stack_depth: integer 類型，聲明服務器執行堆棧的最大安全深度。默認值 2MB。如果發現不能運行復雜的函數，可以適當提高此配置的值，不過通常情況下保持默認值就夠了。
把 max_stack_depth 參數設置得大於實際的操作系統內核限制值時，意味着一個正在運行的遞歸函數可能會導致 PostgreSQL 后台服務進程奔潰。在一些操作系統平台上，PG 能夠檢測出內核限制，這時它將不允許將其設置為一個不安全的值。但PG並不能在所有操作系統的平台都檢測它的限制值，所以還是建議設置一個明確的值。
總結：
shared_buffers：共享內存的大小，主要用於共享內存數據塊。
work_mem：單個 SQL 執行時，排序、hash join 所使用的內存，SQL 運行完成后，內存就釋放了。
shared_buffers 默認值為 32 MB，work_mem 為 1MB，如果你的機器上有足夠的內存，可以把這個參數改得大一些，
這樣數據庫就可以緩存更多的數據塊，當讀取數據時，就可以從共享內存中讀，而不需要再從文件上去讀取。
work_mem 設置大一些，會讓排序操作快一些。