由於是開發階段，所以並沒有配置postgres的引數，都是使用安裝時的預設配置，
以前執行也不見得有什麼不正常，可是前幾天我的cpu資源佔用突然升高.
檢視程序，發現有一個postgres的程序佔用CPU都是80%以上，而且居高不下；
剛開始以為是配置上需要修改，但事實上，預設配置基本上是很優化的，而且是開發階段，資料量也並不大。
後來通過分析，得出結論，解決問題應該從以下幾個方面來逐一考慮：
1：SQL查詢方面
檢查資料檢索的索引是否建立，凡是需要查詢的欄位儘量建立索引，甚至是聯合索引；
建立索引，包括表示式和部分索引；
使用COPY語句代替多個Insert語句；
將多個SQL語句組成一個事務以減少提交事務的開銷；
從一個索引中提取多條記錄時使用CLUSTER；
從一個查詢結果中取出部分記錄時使用LIMIT；
使用預編譯式查詢（Prepared Query)；
使用ANALYZE以保持精確的優化統計；
定期使用 VACUUM 或 pg_autovacuum
進行大量資料更改時先刪除索引（然後重建索引）
2：程式經驗方面

檢查程式，是否使用了連線池，如果沒有使用，儘快使用吧；
繼續檢查程式，連線使用後，是否交還給了連線池；
3：伺服器引數配置
配置檔案postgres.conf中的很多設定都會影響效能，
shared_buffers：這是最重要的引數，postgresql通過shared_buffers和核心/磁碟打交道。
因此應該儘量大，讓更多的資料快取在shared_buffers中，通常設定為實際RAM的10％是合理的，比如50000(400M)
work_mem：在pgsql 8.0之前叫做sort_mem。postgresql在執行排序操作時，
會根據work_mem的大小決定是否將一個大的結果集拆分為幾個小的和work_mem查不多大小的臨時檔案。
顯然拆分的結果是降低了排序的速度。因此增加work_mem有助於提高排序的速度。通常設定為實際RAM的2%-4%，根據需要排序結果集的大小而定，比如81920(80M)
effective_cache_size：是postgresql能夠使用的最大快取，
這個數字對於獨立的pgsql伺服器而言應該足夠大，比如4G的記憶體，可以設定為3.5G(437500)
maintence_work_mem：這裡定義的記憶體只是在CREATE INDEX, VACUUM等時用到，因此用到的頻率不高，但是往往這些指令消耗比較多的資源，
因此應該儘快讓這些指令快速執行完畢：給maintence_work_mem大的記憶體，比如512M(524288)
max_connections：通常，max_connections的目的是防止max_connections * work_mem超出了實際記憶體大小。
比如，如果將work_mem設定為實際記憶體的2%大小，則在極端情況下，如果有50個查詢都有排序要求，而且都使用2％的記憶體，則會導致swap的產生，系統性能就會大大降低。
當然，如果有4G的記憶體，同時出現50個如此大的查詢的機率應該是很小的。不過，要清楚max_connections和work_mem的關係。
有關引數的解釋可見：

http://www.varlena.com/varlena/GeneralBits/Tidbits/annotated_conf_e.html 和 http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html。
4：硬體的選擇
由於計算機硬體大多數是相容的，人們總是傾向於相信所有計算機硬體質量也是相同的。
事實上不是， ECC RAM（帶奇偶校驗的記憶體），SCSI （硬碟）和優質的主機板比一些便宜貨要更加可靠且具有更好的效能。
PostgreSQL幾乎可以執行在任何硬體上，但如果可靠性和效能對你的系統很重要，你就需要全面的研究一下你的硬體配置了。
計算機硬體對效能的影響可瀏覽

http://candle.pha.pa.us/main/writings/pgsql/hw_performance/index.html 和 http://www.powerpostgresql.com/PerfList/。
5：為什麼在試圖連線時收到“Sorry, too many clients”訊息？
這表示你已達到預設100個併發後臺程序數的限制，
你需要通過修改postgresql.conf檔案中的max_connections值來 增加postmaster的後臺併發處理數，修改後需重新啟動postmaster。