，「世界上最好的開源關係資料庫」的最新版本將在幾週內發布（如果一切按計劃進行）。 這遵循了每年一次發布具有大量新功能的新版本的常規時間表，坦率地說，這令人印象深刻。 這就是我成為 PostgreSQL 社群活躍成員的原因。
在我看來，與以前的版本不同，PostgreSQL 12 不包含一兩個革命性功能（例如分區或查詢並行性）。 我曾經開玩笑說，PostgreSQL 12的主要特點是穩定性更高。 這不就是您管理業務關鍵數據時所需要的嗎？
但 PostgreSQL 12 不止於此：透過新功能和改進，應用程式將表現得更好， 您所需要做的就是升級！
（好吧，也許重建索引，但在這個版本中，它並不像我們習慣的那麼可怕。）
升級 PostgreSQL 並立即享受重大改進而無需不必要的麻煩，這將是很棒的事情。 幾年前，我回顧了從PostgreSQL 9.4 到PostgreSQL 10 的升級，並看到由於PostgreSQL 10 中改進的查詢並行性，應用程式的速度如何加快。最重要的是，我幾乎不需要做任何事情（只需設定一個配置參數） max_parallel_workers).
同意，當應用程式在升級後立即運行得更好時，這很方便。 我們非常努力地取悅用戶，因為 PostgreSQL 的用戶越來越多。
那麼簡單升級到 PostgreSQL 12 如何讓您滿意呢？ 我現在就告訴你。
主要索引改進
沒有索引，資料庫就走不遠。 還有什麼方法可以快速找到資訊呢？ PostgreSQL 的基本索引系統稱為 。 這種類型的索引針對儲存系統進行了最佳化。
我們只需使用運算符 CREATE INDEX ON some_table (some_column)，當我們不斷插入、更新和刪除值時，PostgreSQL 做了很多工作來保持索引最新。 一切都像魔術一樣自行運作。
但 PostgreSQL 索引有一個問題 - 它們 並佔用額外的磁碟空間並降低資料檢索和更新的效能。 我所說的「膨脹」是指無效地維護索引結構。 這可能與它刪除的垃圾元組有關，也可能無關 （感謝彼得·加根提供的資訊）））。 在索引主動變化的工作負載中，索引膨脹尤其明顯。
PostgreSQL 12 極大地提高了 B 樹索引的效能，TPC-C 等基準測試的實驗表明，現在使用的空間平均減少了 40%。 現在，我們不僅花在維護 B 樹索引（即寫入操作）的時間更少，而且花在檢索資料上的時間也更少，因為索引小得多。
主動更新其表的應用程式 - 通常是 OLTP 應用程式（) - 將更有效地使用磁碟和處理請求。 磁碟空間越多，資料庫在不升級基礎架構的情況下需要成長的空間就越大。
某些升級策略需要重建 B 樹索引才能利用這些優勢（例如 不會自動重建索引）。 在 PostgreSQL 的早期版本中，重建表上的大型索引會導致嚴重的停機時間，因為同時無法進行變更。 但 PostgreSQL 12 還有另一個很酷的功能：現在您可以與命令並行重建索引 以完全避免停機。
PostgreSQL 12 中的索引基礎設施還有其他改進。 另一件事也有一些魔力—— ，又稱 WAL（預寫日誌）。 預寫日誌記錄 PostgreSQL 中的每個事務，以防發生故障和複製。 應用程式使用它來歸檔和 。 當然，預寫日誌會寫入磁碟，這會影響效能。
PostgreSQL 12 減少了在索引建置期間由 GiST、GIN 和 SP-GiST 索引建立的 WAL 記錄的開銷。 這提供了幾個切實的好處：WAL 記錄佔用更少的磁碟空間，並且資料重播速度更快，例如在災難復原或時間點復原期間。 如果您在應用程式中使用此類索引（例如，基於 PostGIS 的地理空間應用程式大量使用 GiST 索引），那麼這是另一個無需您付出任何努力即可顯著改善體驗的功能。
分區 - 更大、更好、更快
PostgreSQL 10 推出 。 在 PostgreSQL 11 中，它變得更容易使用。 在 PostgreSQL 12 中，您可以變更部分的比例。
在 PostgreSQL 12 中，分區系統的效能顯著提高，尤其是在表中有數千個分區的情況下。 例如，如果一個查詢只影響一個有數千個分區的表中的幾個分區，那麼它的執行速度會快得多。 效能的提高不僅僅是針對這些類型的查詢。 您還會注意到在具有多個分割區的表上執行 INSERT 操作的速度有多快。
記錄數據使用 - 順便說一下，這是一個很好的方法 這是一個例子 — PostgreSQL 12 中的分區表也變得更有效率。 使用 COPY 一切都已經很快了，但在 PostgreSQL 12 中它絕對是飛速的。
由於這些優點，PostgreSQL 允許您儲存更大的資料集並使它們更容易檢索。 而你卻沒有付出任何努力。 如果應用程式有很多分區，例如記錄時間序列數據，簡單的升級將顯著提高其效能。
雖然這不完全是「升級並享受」的改進，但 PostgreSQL 12 允許您建立引用分區表的外鍵，使分區成為一種愉快的工作。
WITH 查詢變得更好了
何時 （又名 CTE，又名WITH查詢），我迫不及待想寫一篇關於 。 這是可以加快應用程式速度的功能之一。 當然，除非您使用 CTE。
我經常發現 SQL 新手喜歡使用 CTE；如果你以某種方式編寫它們，感覺就像你在編寫一個命令式程式。 就我個人而言，我喜歡重寫這些查詢來解決 沒有 CTE 並提高生產力。 現在一切都不同了。
PostgreSQL 12 允許您內嵌特定類型的 CTE，而不會產生副作用（SELECT)，僅在請求結束時使用一次。 如果我追蹤我重寫的 CTE 查詢，其中大多數都屬於這一類。 這有助於開發人員編寫清晰的程式碼，現在也可以快速運行。
此外，PostgreSQL 12 本身優化了 SQL 執行，而無需您執行任何操作。 雖然我現在可能不需要最佳化這類查詢，但 PostgreSQL 繼續致力於查詢最佳化真是太好了。
即時 (JIT) - 現在默認
在支援的 PostgreSQL 12 系統上 預設啟用 JIT 編譯。 首先，你會得到支持 對於一些內部操作，其次，在選擇列表（SELECT 之後的）中使用表達式（最簡單的例子是 x + y）、聚合、帶有 WHERE 子句的表達式等的查詢可以使用 JIT 來提高效能。
由於 PostgreSQL 12 中預設啟用 JIT，因此效能會自行提高，但我建議在引入了 JIT 的 PostgreSQL 11 中測試應用程序，以測量查詢效能並查看是否需要調整任何內容。
PostgreSQL 12 中的其他新功能怎麼樣？
PostgreSQL 12 擁有大量很酷的新功能，從使用標準 SQL/JSON 路由表達式檢查 JSON 資料的能力到使用參數的多重驗證 clientcert=verify-full、創作專欄等等。 足夠單獨發表一篇文章了。
與 PostgreSQL 10 一樣，PostgreSQL 12 在升級後將立即提高整體效能。 當然，您可以有自己的路徑- 在啟用改進之前在生產系統上的類似條件下測試應用程序，就像我對PostgreSQL 10 所做的那樣。即使PostgreSQL 12 已經比我預期的更穩定，也不要懶於測試在將應用程式投入生產之前，對其進行徹底的檢查。
來源： www.habr.com