本節書摘來自異步社群出版社《postgresql 9.0性能調校》一書中的第1章，第1.1節，作者： 【美】gregory smith，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
這個測試給出了每秒處理事務數（tps, transactions per second）系統整體速度的資料值，可以在隻讀模式下或包含寫入的模式下運作。在隻讀模式下，從8.0版本更新到8.1版本的性能提升4倍，而8.3版本的性能提升則再提高2倍左右。如表1-1所示。
在負載峰值情況下用戶端數量的上升給出了資料庫内部處理通路共享資源程度大小的一種思路。特别是8.1系列版本當中包含了一些重大的更新。而在寫入模式下的性能改進與此類似，8.0版本到8.3版本之間性能幾乎達到了8倍的增益，見表1-2。
在這些測試當中可以看出8.3版本到8.4版本性能有略微的降低，這是由于對資料庫進行了細微的重新調整，以改善其在最糟糕情況下的性能。8.4版本中采集了更多的統計資料用于提高複雜索引的性能，并在測試中犧牲了部分不太重要排序的速度。第10章将會講述更多關于這方面的詳細内容。
盡管結果不會涵蓋如此廣泛的版本，但其他的測試結果也證明了性能的提升。可以很容易地看出，在2005年年底之前8.1版本傳遞的時候，之前所達成的關于postgresql性能的結論是完全過時的。2008年8.3版本釋出的時候，速度提升可以算是一個很大的飛躍。是以，8.3之前的版本并不能代表目前的性能，同時首選使用這個版本或者後續版本還有很多其他的原因。
如果使用者有較老版本的postgresql系統，并想讓它運作得更快一些，因為新版本的這些令人矚目的特性，首要的事情不是考慮如何調整設定，而是應該考慮更新到最新版本的可能性。如果使用者正在實施一個新的項目，使用者可以考慮最新的8.3版本。除了性能提升外，該版本還有一些影響到應用程式編碼變化，使用者可以更容易開始項目的實施，避免後期的改進。
第16章包含一個參考指南，其内容為從8.1版本至9.0版本當中每個主要的postgresql版本所加入的與性能相關功能的介紹。使用者可能會發現隻有在最新版本裡的功能能夠引起他們的注意，是以強烈建議使用者使用最新的版本。在本書中将會突出這些特定版本的變化。
目前為止，從現有的<code>postgresql</code>版本更新（例如從8.1.x版本更新到8.2.x版本）到最新的主要版本的惟一方法是dump轉儲和重載。使用新版本中的<code>pg_dump</code>和/或<code>pg_dumpall</code>程式将整個資料庫的内容寫入一個檔案。采用這樣的方法，如果有任何變更需要進行更新，那新的轉儲程式可以嘗試處理它們。并不是所有的更新變更都會自動進行。随後，根據使用者要轉儲的格式，可以運作它所生成的腳本或者是使用<code>pg_restore</code>程式來處理這個任務。<code>pg_restore</code>是在新版本的<code>postgresql</code>中的一個較好的替代方案，具有并行存儲的功能。
圖示
如果使用者正在使用的作業系統并不允許使用者在同一時間内運作多個postgresql版本，例如現行的redhat linux的rpm包，在同一時間内同時安裝一個老的postgresql版本和一個新的postgresql版本是很困難的。在postgresql 9.0中，對這種情況所做的一些改進也在開發當中。是以在進行更新規劃時，要将确認運作多個版本的可行性作為其中的一個部分。
轉儲資料需要一定的時間，恢複資料要花的時間更久。在這種情況下，資料庫可能要暫停服務，這樣才能保證沒有其他的任何更改被寫入到轉儲檔案中。對于大型的資料庫，停機的時間可能會很長而且是讓人無法接受的。
在一些要求較高的環境中，資料庫要求當機時間為0，以達到7×24小時運作。在這種情況下，轉儲和重載是不适用的。直到最近，針對這種環境使用所進行的postgresql更新，惟一有效的方法是slony的複制。slony是最受歡迎的解決方案，第14章有其更詳細的介紹。slony當中的一個功能就是使用者可以不在所要進行複制的所有節點都運作相同版本的postgresql。使用者可以提取一個新的節點來運作新版本的postgresql，等待複制完畢後，一旦與源相比對，那麼将其進行切換。
postgresql開發社群目前決定将就地更新功能應用于未來的版本中。現在，tb以及更大資料量規模的postgresql的安裝已經很普遍，是以更新時隻使用轉儲和重載是不實際的。
1．從更早的版本更新到postgresql 8.3+
8.3版本的主要内部變化是從更早版本進行更新當中不需要轉儲整個資料庫并進行重載到更新的版本。這讓8.3版本成為其發展史上的重要裡程碑。與8.2版本相比較，不僅僅速度上快很多，一旦使用者使用了8.3版本，從此就可以使用就地更新功能了。
2．次要版本的更新
雖然更新多少都會有些風險，postgresql次要版本僅修複經常碰到的安全性和資料損壞錯誤，以減少更新的風險。postgresql社群認為不更新比更新的風險高。
在postgresql次要版本更新當中，永遠不會找到會破壞應用程式的任何一種不可預期的修改。漏洞、安全和損壞性修複總會以一種最小化引入外部可視的行為變化幾率的方式被執行。如果是無法避免的話，那麼将會在發行說明當中詳細地去解釋其中的原因以及建議的解決方案。在其中将會發現一些細微的問題，這是由于某些已解決的缺陷所帶來的，這甚至會在一個次要版本的更新之後得到徹底解決。從postgresql郵件清單當中不難發現某個問題的報告已經在相容該版本的一些最新的次要版本更新當中被解決，是以更新到該版本是使所有這些問題消失的主要需求。