PostgreSQL 15 stats collector 在取消後是如何實現的原有功能的

在POSTGRESQL 15 有一個重要的功能去掉了stats collector 在說為什麼去掉這個stats collector 的問題前，我們先得弄清出stats collector 到底是一個什麼功能。 

首先stats collector 並不是有些同學理解的對於表的 analyze,實際上這個功能統計了表和索引的訪問情況，同時也跟蹤每個表的行數以及表進行vacuum 和analyze的活動記錄，另外在自己的程式中，還可以檢視其他程式正在操作的情況，也是透過 stats collector來進行的。

統計資訊的收集也有引數可以進行調整，如 track_counts, track_function， track_activities 等都可以開啟會關閉，減少或增加統計資訊收集的內容，增加或減少系統的負擔。

那麼與收集資訊有關的部分儲存在(部分VIEW 並不全)

pg_stat_activity

pg_stat_bgwriter

pg_stat_database

pg_stat_database_conflicts

pg_stat_replication

pg_stat_all_tables

pg_stat_sys_tables

pg_stat_user_tables

pg_stat_all_index

pg_stat_user_indexes

pg_statio_user_tables

pg_statio_sys_tables

pg_statio_all_indexes

pg_statio_user_indexes

透過下面的語句可以檢視當前正在工作的

SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
       pg_stat_get_backend_activity(s.backendid) AS current_query
    FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;


那麼說了這麼多，在PG15 中為什麼要替換了這個功能，那麼必然是有問題
才進行替換。
其中潛在的因素是
1 基於PG15 之前的需要收集的資訊來自於每個backend 程式，而針對每
個程式的資訊的收集不是一個容易完美實現的事情，
2 每個程式需要將資訊傳送給 stats collector 程式，傳送的方式是通
過UDP的方式進行，但基於UDP的方式的路徑並不是一個可靠的模式
其中會包含一些問題，如state statistics , stats collector 工作的情況，
autovacuum 工作捕捉的問題。
3  效能的消耗也是一個傳統使用 stat statistics 的問題，如
我們可以從下圖PG14中檢視到，

DEBUG:   writing stats file "pg_stat_tmp/global.stat"
DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"
DEBUG:  autovacuum: processing database "postgres"
DEBUG:  received inquiry for database 13881
DEBUG:  writing stats file "pg_stat_tmp/global.stat"
DEBUG:  writing stats file "pg_stat_tmp/db_13881.stat"
DEBUG:  writing stats file "pg_stat_tmp/db_0.stat"
相關的儲存空間，來儲存相關的資料的目錄 （介於PG14）

基於這些問題，PG15 做出了絕大的改造，將原有在檔案系統或者檔案中
實現的state statistics 實現的方式轉移到了 dynamic shared memory 中。

以前，統計資料收集器透過UDP接收統計資料更新，並透過定期將統計數
據寫入臨時檔案來共享統計資料。這些檔案可以達到幾十兆位元組，每秒
寫入兩次。

現在統計資訊儲存在共享記憶體中。變數編號物件的統計資訊儲存在dshash
雜湊表中(由動態共享記憶體支援)。固定編號的統計資料儲存在普通共享內
存中。

* Each statistics kind is handled in a dedicated file:

  70  * - pgstat_archiver.c

  71  * - pgstat_bgwriter.c

  72  * - pgstat_checkpointer.c

  73  * - pgstat_database.c

  74  * - pgstat_function.c

  75  * - pgstat_io.c

  76  * - pgstat_relation.c

  77  * - pgstat_replslot.c

  78  * - pgstat_slru.c

  79  * - pgstat_subscription.c

  80  * - pgstat_wal.c

但是細心的讀者可能發現，在POSTGRESQL15的環境中還存在pg_stat_tmp 目錄的原因主要還是在於部分基於原有 POSTGRESQL 設計中的一些東西還需要使用這個目錄，所以需要保留，而不是POSTGRESQL 本身還在需要這個目錄。比如 pg_stat_statement 模組就還需要這個目錄來存放檔案。

但隨著POSTGRESQL 的統計資訊在記憶體中進行工作的情況，統計資訊的及時性將被挑戰，所以在POSTGRESQL 15 中新新增了一個新的引數，stats_fetch_consistency  這個引數主要的目的是在實現了新功能後，的資料被查詢時的資訊一致性，總體的值有 none , cache , snapshot, 我們建議使用預設值即可，如果效能有更高的要求，對於資料的準確性要求不高，則使用 none ， 如果對於資訊的要求性特別高，需要使用效能最差的snapshot

但是在系統運作的過程中，難免會有系統異常，導致的系統崩潰，而在這樣的情況下，統計資訊在記憶體中並不能安全的全部重新整理到我們的磁碟系統中，所以如果遇到系統的崩潰則記憶體中的統計資訊會被拋棄掉。

PgStatsDSA Waiting for stats dynamic shared memory allocator access

PgStatsHash Waiting for stats shared memory hash table access

PgStatsData Waiting for shared memory stats data access

另外後續在POSTGRESQL 中出現的基於狀態收集的部分的提示有以上三種，如果需要觀察相關狀態收集的部分，可以關注日誌中相關的資訊。