PostgreSQL 19 新增四張系統視圖,鎖爭用與 autovacuum 排序終於攤在陽光下
PostgreSQL 官方發行說明 · 2026-09-01
PostgreSQL 19 在系統目錄新增了 pg_stat_lock、pg_stat_recovery、pg_stat_autovacuum_scores、pg_dsm_registry_allocations 四張系統視圖,同時調整了 max_locks_per_transaction、log_lock_waits 等多項與鎖、複寫、autovacuum 相關的預設行為。這些變更記錄在官方 PostgreSQL 19 Release Notes 中,ClickHouse 工程團隊在 部落格文章進一步解讀了這些欄位在維運排查上能派上用場的地方。
核心改動:鎖與復原狀態不再需要拼湊多個函式
pg_stat_lock 把過去分散在 pg_locks 快照裡的鎖等待行為,彙整成累積式的統計視圖。它以 locktype 為單位(relation、transactionid、tuple、extend、page、object、advisory、virtualxid、spectoken、applytransaction、frozenid、userlock 共 12 種),每種鎖類型一列,記錄以下欄位。
waits:等待時間超過deadlock_timeout(預設 1 秒)的次數wait_time:累積等待毫秒數fastpath_exceeded:fast-path 鎖槽用盡的次數stats_reset:統計上次重置的時間
這張視圖背後由新函式 pg_stat_get_lock() 供給資料,可用 pg_stat_reset_shared('lock') 重置,由 Bertrand Drouvot 提交。pg_stat_recovery 則是把 standby 復原狀態的多次函式呼叫,壓縮成單一原子快照。只能在 standby 上查詢,且需要 pg_read_all_stats 權限。
關鍵欄位包含 promote_triggered(是否正在 promote)、last_replayed_read_lsn / last_replayed_end_lsn(最後重播的 WAL 位置)、last_replayed_tli(timeline ID),以及 pause_state(值為 not paused / pause requested / paused)。由 Xuneng Zhou 提交,Shinya Kato 修正。
SELECT locktype, waits, wait_time, fastpath_exceeded
FROM pg_stat_lock
ORDER BY wait_time DESC;autovacuum 改用分數排序,不再依 pg_class 順序執行
pg_stat_autovacuum_scores 把每張表在 autovacuum 排程中的優先順序,轉成可查詢的分數。每張表一列,score 欄位取 xid_score(交易 ID 老化)、mxid_score(multixact ID 老化)、vacuum_score、vacuum_insert_score、analyze_score 五個分項中的最大值作為排序依據;do_vacuum、do_analyze、for_wraparound 三個布林欄位標示接下來會採取的動作。這代表 autovacuum 的執行順序,從過去單純按 pg_class 順序掃描,改成依風險與過期程度排序處理。
對應這張視圖,PostgreSQL 19 也新增五個權重型 GUC,預設值都是 1.0。由 Sami Imseih 提交主體視圖,Nathan Bossart 調整排序邏輯。
| 參數 | 作用 |
|---|---|
autovacuum_freeze_score_weight | 交易 ID 老化權重 |
autovacuum_multixact_freeze_score_weight | multixact ID 老化權重 |
autovacuum_vacuum_score_weight | 一般 vacuum 權重 |
autovacuum_vacuum_insert_score_weight | insert-only 表 vacuum 權重 |
autovacuum_analyze_score_weight | analyze 權重 |
DSM 配置與其他監控欄位補齊
pg_dsm_registry_allocations 列出所有透過 DSM registry 配置的動態共享記憶體。DSM registry 本身是 PostgreSQL 17 就導入的機制,讓擴充套件(extension)能取得共享記憶體區塊而不必重啟資料庫;19 版補上的這張視圖,讓每筆配置的 name、type(segment / area / hash)、size(位元組,失敗則為 NULL)都能直接查詢,不必再翻原始碼猜測擴充套件用了多少記憶體。由 Florents Tselai 提交,Nathan Bossart 補上擴充套件端支援。
官方 release notes 同時列出多項既有視圖的欄位擴充,包括 pg_stat_replication_slots 新增 mem_exceeded_count(記錄 logical_decoding_work_mem 被超過的次數)與 slotsync_skip_count / slotsync_last_skip / slotsync_skip_reason 三個複寫槽同步欄位;pg_stat_progress_vacuum 新增 started_by 與 mode;pg_stat_all_tables、pg_stat_all_indexes、pg_statio_all_sequences 都補上 stats_reset 欄位。
影響範圍:預設值變動影響現有部署
max_locks_per_transaction 的預設值從 64 調整為 128,但官方特別註明這不是單純加倍容量。因為鎖的記憶體配置方式一併改變,舊版本手動調高過這個參數的部署,需要重新用兩倍數值才能維持相同的鎖容量上限。同時 log_lock_waits 改為預設啟用,代表升級後 log 檔案裡會自動多出鎖等待紀錄,若原本沒有針對這類 log 做輪替或過濾設計,需要留意 log 量的變化。
這一批系統視圖多由 Bertrand Drouvot、Sami Imseih、Nathan Bossart 等核心貢獻者提交,對應的是維運上長期只能靠 pg_locks 快照、pg_stat_activity 或直接讀原始碼推敲的排查工作,現在多了穩定的查詢介面。
原始來源:PostgreSQL 19 Release Notes、ClickHouse Blog: New system views in PostgreSQL 19
ClickHouse 發布 Agentic Analytics Benchmark:28 個模型解 201 道真實分析題,規劃錯誤才是主要死因
ClickHouse Blog · 2026-09-01
ClickHouse 在部落格文章中發布了一個代號 Data Agent MNIST 的評測基準,測試對象是「不給 schema、要求模型自主探索資料庫結構並反覆下查詢,最終產生正確分析答案」的代理型任務。這次評測涵蓋 28 個模型、201 道題目,並在 GitHub 開源了完整的評測框架 data-agent-mnist,讓其他團隊可以拿自己的資料倉儲重跑同一套方法論。
題目來源:從內部分析代理的真實提問過濾而來
這 201 道題目不是憑空設計,而是從 ClickHouse 內部分析代理 DWAINE 的真實使用紀錄裡篩選出來的。篩選漏斗從 501 個候選提問開始:先用零樣本分類移除非問句與依賴上下文的提問剩 475 個,再依 schema 相容性篩到 243 個,經過真實答案(ground truth)覆核剩 204 個,最後法律審查再拿掉 3 個,收斂成 201 題。
所有題目都經過去識別化處理:PII 用確定性方式替換,自由文字中的姓名先用零樣本任務抽取,帳務數字則等比例縮放。建置流程會對任何殘留的結構化 token 直接判定失敗,私有測試集裡還埋了金絲雀字串(canary strings)防止外洩比對。
合成資料倉儲:18 張表、865 個欄位、雙層結構
題目要在一個重建出來的合成資料倉儲上作答,規模是 18 張表、共 865 個欄位。倉儲分兩層:mart 層(dbt_marts_general)是攤平過的商品與帳務資料,共 235,000 列;dimensional 層(dbt_dds)則是星狀結構的 CRM 資料,共 746 個欄位,需要多層 join 才能拿到答案。資料產生方式採「稻草堆裡找針」(needle-in-haystack)策略:先在合成母體中埋入題目會用到的實體,母體本身涵蓋 12 個地區、10 個產業、18 個月的歷史紀錄,模擬真實分佈。
Ground truth 與評分:多數決加三方陪審
每一題的標準答案由三個前沿模型(Claude Opus 4.8、GPT-5.5、Gemini 2.5 Pro)各自獨立解題後多數決產生。三個模型全部同意的比例是 51.7%;若三方各執一詞、完全沒有共識,這題就直接捨棄,總共丟了 39 題。比對候選答案與標準答案時,使用欄位對應(column-linked equivalence)、列對齊與數值容差三種機制綜合判定——其中 84.9% 的比對結果必須先做欄位映射才能配對成功,顯示同一份資料在不同模型手中會長出不同的欄位命名與聚合方式。
正確性之外,每個候選答案還要過三席 LLM 陪審團這一關。陪審團由 Anthropic、OpenAI、Google 各出一席評分,規則是不能評自己家族的模型,以多數決定案。事後做的偏誤稽核發現評分寬鬆度會因陪審員而異(同源殘差落在 ±0.9 至 1.2 分之間),但沒有觀察到系統性的護航自家模型的傾向。
28 個模型的排名與成本
正確率最高的是 Claude Fable 5.1,達到 76.6%,但成本也最高。排名前五名如下:
| 模型 | 正確率 |
|---|---|
Claude Fable 5.1 | 76.6% |
DeepSeek V4 Pro | 74.6% |
Claude Fable 5 | 74.3% |
GPT-5.6 | 74.1% |
GPT-5.5 | 73.1% |
其餘模型中,Gemini 3.5 Pro 為 71.8%,Qwen QwQ-32B 為 68.2%,Gemini 2.5 Pro 為 66.8%,DeepSeek V4 Flash 為 65.7%。前 12 名的排名中有 5 個是開權重模型,前沿閉源模型仍佔多數席次。
成本與正確率之間的落差相當懸殊。跑完全部 201 題,最便宜的 DeepSeek V4 Flash 只要 1 美元,而正確率最高的 Claude Fable 5.1 要價 52 美元,但兩者的正確率只差 11 個百分點。
污染檢測:對照 Spider 基準的相似度差異
ClickHouse 用實體還原測試檢查資料是否洩漏進了模型訓練集,結果所有模型在全部 650 次還原嘗試中都只有雜訊等級的表現,沒有偵測到污染。對照組是 Yale 大學發布、公開多年的 Spider text-to-SQL 基準——由於 Spider 的開發集長年掛在 GitHub 與 HuggingFace 上供下載,已知容易被模型在預訓練階段見過。
ClickHouse 量測到模型輸出與 Spider 開發集的相似度高達 0.89,但與 Data Agent MNIST 的相似度只有 0.06,以此佐證這批新題目確實沒有被模型記憶過。
影響範圍:失敗大多發生在規劃階段
拆解所有失敗案例後,規劃錯誤(而非 SQL 語法或執行錯誤)是壓倒性的主因。各模型的失敗案例中有 53% 到 82% 屬於「查詢規劃錯誤」——例如選錯表、漏掉必要的 join、誤解欄位語義,而實際下達的 SQL 語句執行失敗的比例微乎其微。
另外,對星狀結構的 dimensional 層做欄位探索時,表現最好的模型能達到 87–98% 的準確率,較弱的模型只有 47–55%,顯示多層 join 的 schema 探索能力是拉開模型差距的關鍵環節之一。ClickHouse 將整套框架開源,讓其他團隊能用自家倉儲重跑同一套方法論,而不必只看公開排行榜的分數。
原始來源:ClickHouse Blog: The Agentic Analytics Benchmark、GitHub: data-agent-mnist
Uken Games 用 ClickHouse 重建可觀測性堆疊,一年省下 87% Datadog 費用
ClickHouse Blog · 2026-09-01
手機遊戲公司 Uken Games 把原本建立在 Datadog 上的可觀測性系統,換成以 ClickHouse 為核心的自建堆疊。根據 ClickHouse 部落格文章轉述工程師 Alexei Zenin 在 2026 年 6 月多倫多 meetup 的分享,這次遷移在服務零停機的前提下完成,年度可觀測性成本下降 87%。文章描述的環境規模是 300 個容器、50 多台 EC2 主機、100 多顆磁碟與數十個資料庫,外加 100 多個服務部署。
原本的問題:成本失控與供應商鎖定
Uken Games 用 Datadog 監控前述規模的基礎設施,但成本持續攀升,即使做了各種優化仍壓不住。更麻煩的是 Datadog 的專屬 agent 已經深度整合進基礎設施各個角落,形成供應商鎖定,難以抽換。定價模型本身也開始反過來影響架構決策——文章提到單純因為 serverless 與 EC2 的計價方式差異,就會讓人選擇不同的部署形態,而不是單純依照工程需求決定。
Datadog 的計價結構本身也相當繁瑣。文章列出的其中兩種計價方式是 $0.002/容器/小時,或是預付制的 $1/容器/月,團隊得自行判斷不同工作負載該套用哪種費率才划算,這種認知負擔本身就是一種隱性成本。
採用的方法:OpenTelemetry 加 ClickHouse,三種資料各自分流
新架構的第一層是全面改用 OpenTelemetry 作為與供應商無關的資料收集標準。收集端採兩層式部署:ECS 執行個體上跑輕量 agent,後面接一層會自動擴縮的 gateway,agent 到 gateway 之間走 localhost 通訊,盡量降低對應用程式本身的額外負擔。
三種可觀測性資料(trace、metrics、log)刻意分流到三個不同的後端,而不是全部塞進同一個系統。Trace 主力儲存是單一節點的 ClickHouse,總磁碟用量約 170 GB;metrics 交給 AWS 代管的 Prometheus,理由是考量日後的可攜性;log 則留在 CloudWatch,因為這塊的成本影響相對較低,沒有急迫的搬遷誘因。APM 視覺化層用的是建立在 ClickHouse 之上的開源工具 SigNoz,儀表板與告警則統一用 Grafana 同時查詢這三個資料來源。
# 兩層式 OpenTelemetry 收集架構(概念示意)
ECS instance agent (localhost)
│
▼
auto-scaling gateway layer
│
▼
ClickHouse (trace) / AMP (metrics) / CloudWatch (log)為了控制資料量,團隊對 trace 做了取捨式取樣。錯誤 trace 與高延遲請求全部保留,成功請求則只保留有統計代表性的 5–10% 樣本;所有資料的保留期限統一設定在兩週,原因是這類遙測資料沒有法規要求的更長保留義務。告警規則改用 CloudFormation 程式碼佈建,取代過去手動在 Grafana 介面上點設定的做法。
實際效果:每年省下約 12,000 美元,查詢量不減反增
遷移後的年度可觀測性支出比原本的 Datadog 費用降低 87%,換算成金額約為每年 12,000 美元。整個過程對外部玩家而言是零停機切換,原有服務持續服務數百萬名玩家不受影響。文章指出達到與 Datadog 相當的功能覆蓋度(feature parity)後,工程團隊投入這次遷移的時間成本,在兩年內就透過省下的費用打平。
新堆疊上線後,Grafana 對三個資料來源的查詢量達到每分鐘約 600 次。這個查詢量代表遷移後的系統不只是把舊功能原封不動搬過來,而是在維持既有可觀測性覆蓋度的同時,讓查詢與告警的使用頻率維持在原本的量級,沒有因為換架構而讓團隊減少對監控資料的依賴。
原始來源:ClickHouse Blog: How Uken Games reduces observability costs by 87% with ClickHouse