PG 的 HOT 什麼時候會失效？
兩份材料對 HOT（Heap Only Tuple） 的預設剛好相反，而兩邊都沒講清楚它什麼時候成立、什麼時候不成立。這則筆記把問題留著。
兩種相反的預設
| 來源 | 它把 HOT 當成 | 原話 |
|---|---|---|
| 建索引的代價是毫秒，收益可能是秒（Victor Gardini 的 EXPLAIN 指南） | 常態 | 「只改無關欄位時 PostgreSQL 的 HOT 機制可能連索引都不用碰」 |
| 這篇 MySQL vs PG 的分析 | 註腳 | 主線是「所有索引都要更新指向新位置」，HOT 只是「可以緩解此問題，但仍有限制」 |
兩者差別不小：若 HOT 是常態，PG 的寫入放大來自位置過期，不是欄位變動 就被大幅削弱；若 HOT 常失效，那條規則就是 PG 的日常成本。
要查清楚的
- HOT 成立的完整條件是什麼？（我的推論是「新版本要能放進同一個 page 的剩餘空間」＋「沒有改到任何索引欄位」，但這是推論，不是材料說的）
- fillfactor 設定與 HOT 的關係？為什麼調低 fillfactor 會被建議？
- 一旦同頁塞不下，是整串 HOT chain 斷掉還是只有這次失效？
- 實務上怎麼觀測 HOT 命中率？（
pg_stat_user_tables.n_tup_hot_upd？）
結案條件
讀到 PostgreSQL 官方文件的 HOT 章節，或自己做一次實測（同一張表分別改索引欄位／非索引欄位，比對 n_tup_hot_upd）。結案後回來修正上面兩篇的說法。