摘要：以前，統計信息收集器通過UDP接收統計信息更新，并通過定期將統計信息數據寫出到臨時文件來共享統計信息數據。當文件達到數十兆字節時，每秒最多寫出兩次，這會阻止添加其他有用的統計數據。現在，PostgreSQL 15將做出了重大的改變，開始使用動態共享內存來收集統計信息，而不再使用文件和文件系統。
https://www.percona.com/blog/postgresql-15-stats-collector-gone-whats-new/
聲明：本文為CSDN翻譯，轉載請注明來源。
作者 | Jobin Augustine
譯者 | 朱珂欣 責編 | 屠敏
出品 | CSDN（ID：CSDNnews）
眾所周知，PostgreSQL是一個功能強大的開源對象關系數據庫系統，它使用并擴展了SQL語言，并結合了許多可安全存儲和擴展最復雜數據工作負載的特性。一直以來，PostgreSQL都在業內擁有極高的聲譽，它的每一次版本的發布，都能在國內外獲得很大的關注度。
2022年6月30日，PostgreSQL全球開發組宣布PostgreSQL 15的第二個beta版本已可供下載，該版本包含將于2022年末發布的PostgreSQL 15正式版本中的所有特性和功能。
很多人將PostgreSQL 15與PostgreSQL 14相比較，就會發現有一個特別的更新——"統計信息收集器"不見了。曾經是無數開發者的開發瓶頸，如今已經永遠消失了。作為PostgreSQL 14和更早版本都需要“統計信息收集器”，它存在怎樣的問題呢？PostgreSQL 15又新增了什么樣的功能？
被舍棄的統計信息收集器
PostgreSQL的統計信息收集器，是一個支持收集和報告服務器活動信息的子系統。它可以對表和索引的訪問計數，以此累計統計信息。并且，還可以跟蹤每個表中的總行數、每個表的清理和分析動作的信息，以及統計調用用戶定義函數的次數和在每次調用中花費的總時間。
但是，PostgreSQL的統計信息收集器同樣存在一些問題。
-
信息傳輸受到阻力。
由于會話的每個后端是PostgreSQL中的單獨進程，因此，收集統計信息并傳輸并不是容易的事。每個后端將有關它們執行的活動信息發送到單個“統計信息收集器”進程。在過去，這種通信是通過UDP套接字進行，在用戶報告的不同類型問題中顯示，有三類問題較為明顯：統計數據過期；統計數據收集器不運行；自動真空不工作/不啟動等。
并且，在過去如果統計數據收集器在特定機器上出現問題，用戶其實很難理解出了什么問題。
-
大量IO出現。
“統計信息收集器”還有一個不利影響——它引起的IO。如果啟用DEBUG級別 2，可能會看到不斷出現在PostgreSQL 日志中的消息，將導致數據目錄所在的裝入點上出現大量 IO。
下圖是參數值stats_temp_directory所指向的位置。在許多系統上，它將是數據目錄中pg_stat_tmp。在Ubuntu/Debian上，它將在/var/run/postgresql中，例如：
PostgreSQL 15中的新動作
面對統計信息收集器帶來的弊端，如今，PostgreSQL 15開始使用動態共享內存來收集統計信息，而不再使用文件和文件系統。
正如Andres Freund在文中提及的：
以前，統計信息收集器通過UDP接收統計信息更新，并通過定期將統計信息數據寫出到臨時文件來共享統計信息數據。這些文件可以達到數十兆字節，并且每秒最多寫出兩次。這會阻止我們添加其他有用的統計數據。 現在，統計信息都存儲在共享內存中。可以變化的編號對象的統計信息，存儲在由動態共享內存支持的 dshash 哈希表中。固定編號的統計信息，存儲在普通共享內存中。pgstat.c 的標題包含體系結構的概述。 不再需要統計信息收集器，請將其刪除。
顯然，參數stats_temp_directory已經消失。因此，不再需要pg_stat_tmp目錄了，pg_stat_tmp目錄是在數據目錄或其他位置中創建的，所有統計文件都在此生成和讀取。然而，仍保留它是因為不會破壞許多依賴于該目錄的擴展，例如pg_stat_statements。
在加載擴展庫之前，目錄保持為空。例如，如果我們加載pg_stat_statements庫，目錄中會出現一個文件。
當然，這些擴展都并非免費的，需要成本。
在新架構中，大多數統計更新時，首先需要在每個進程中本地累積為"pending"（每個后端都有一個后端本地哈希表）。"pending"是指已累積但尚未提交到共享統計系統的待定信息。在提交后或超時后，會被刷入共享內存。
由于統計信息是在有人試圖讀取時被并發更新的，所以讀取一致性就成了問題。為了解決讀取一致性的問題=PostgreSQL 15引入了一個新的參數：stats_fetch_consistency。它可以取三個值，none、cache 、snapshot：
-
“none”是最有效的。如果存在期望的監視查詢，則無法提供讀取一致性。但對于大多數使用來說是可以的。
-
“cache ”能確保重復訪問產生相同的值，對于涉及自聯接的查詢很重要。
-
“snapshot”在以交互方式檢查統計信息時很有用，但開銷更高。
stats_fetch_consistency的默認值為“cache ”。
更新迭代中的疑問與解答
面對PostgreSQL 15新版本中的重大調整，很多用戶也會產生相關的疑惑。
-
統計信息位于共享內存中，如何在重新啟動后保存？
統計信息在關機前，由檢查點進程寫出到文件系統，并在啟動期間由啟動進程再次裝回。像往常一樣，如果發生崩潰，統計信息將會失效。
-
新功能會影響監控工具/腳本嗎？
顯然是不會，所有的統計監測視圖pg_stat_*仍能照常工作，但需要為stats_fetch_consistency選擇適當的值。如上所述，保留pg_stat_tmp目錄是為了不破壞使用這種方法開發的擴展。但是，擴展開發人員需要針對PostgreSQL 15徹底測試擴展。
-
如何使用PostgreSQL等待事件，了解PostgreSQL及其會話在哪里花費的時間呢？
日常生活中使用的數據收集和分析工具，例如pg_gather，利用這些等待事件分析和了解問題。 因此，為了更好地監控，PostgreSQL還引入了三個新的等待事件。
-
PgSta tsDSA： 等待統計動態共享內存分配器訪問。
-
PgStatsHash： 等待stats共享內存哈希表訪問。
-
PgStatsData： 等待共享內存統計數據訪問。
總的來說，PostgreSQL 15不再需要統計信息收集器，而是將統計信息都存儲在共享內存中。隨著統計收集器及其維護的所有開銷的消失，其他子系統，例如自動真空系統，工作量將大大減少，經常查詢統計信息的監控工具將會大大降低系統的負載。
