起
これはPostgreSQLのDBを見守る一人のDBエンジニアの所感と推測で、間違っているかもしれませんが、現象としてこういうことがあるというメモ書きとしてこれを残します。
PostgreSQLのタプルとはなにかとか、行がどうやってファイルの中におさまってるかを知っておくと書いてあることがイメージしやすいです。
yamamotodinはPostgreSQLについて、明確に意識したバージョンとして 7 から、断続的に 8, 9 , 11, 15 と見てきました。
9以前はオンプレで、11以降はAzureだったりAWSだったりとクラウド上にあるDBです。
今ではdockerでインスタンスを起動して実験したり開発もします。
同じくらいMySQLも使います。
時間的な長さとしては・・曖昧なんですがちゃんとDBのエンジニア（あるいはチューナー）としてPostgreSQLと相対したときから１５年間くらいちょくちょくつきあってるんじゃないかなと思います。
承
そんな私が見た中で「auto vacuumが行われてるはずだけど動いてないように見えてるけどなんで？統計情報とかクソ狂うんだけど」という現象の発生するデータベース(テーブル？)が稀にあります。
逆に頻繁にCRUDしてるけど適切に断片化の解消や統計情報の更新が行われるテーブルもあります。
この差はなんなのかほんとにわからないけれど、現象から仮説を立てられる程度には情報を得たと思うので少しまとめてみたいと思います。
転
まず公式の auto vacuum のドキュメントを読んでみましょう。
ANALYZEが行われるタイミング？について下記の記述があります。
25.1.6. 自動バキュームデーモン
...
解析閾値 = 解析基礎閾値 + 解析規模係数 * タプル数
ふむ、ワイ頭わるいからわからん。
というか和訳されたらほんとにわからなくなるのが技術文章、原典をあたろう・・
が、長期間統計情報が更新されないテーブルは、コレをすり抜ける何かがあるということだろうな。
analyze threshold = analyze base threshold + analyze scale factor * number of tuples
つまり、システムパラメータの autovacuum_analyze_threshold と autovacuum_analyze_scale_factor で同じことをする、と言いたいんだな。
AWS RDS で PostgreSQL 11 と 15 で同じ数字でした・・ということは両者で変化はない、ということだな。
だったらまた断片化しますね。
なお、 autovacuum_analyze_threshold が空白の場合デフォルトの 50 タプルが使用される。
不可解なのは、autovacuum_analyze_scale_factor = 0.05 ということ。
単純に考えると、 5% 増えたら統計情報更新するゼ・・って言ってるように見えるけど、前述の通り更新されないケースがある。
しきい値は タプル数 であるため、
x = 50 + 0.05 * テーブルの全体のタプルの数
x が前回ANALYZEかかったときより多ければ再度ANALYZE..
いくつかのパターンで考えてみよう
たとえば最後にANALYZEしたのが １０，０００ 行（タプル）になったときだとしよう。
そこから次のANALYZEが発生するタイミングは下記の通り
x = 50 + 0.05 * 10,000
x = 550
つまり 550 行増えたとき。
テーブルのタプルの数が10万行だとこの数字は 5050 だし、 100 万行だと 50050 だろう。
・・・すり抜ける隙、なくない？
結？
だが事実として統計情報が更新されていないのか、はてまた別な要因かよくわからんけど実行時間が長くかかるケースはある。
あ、VACUUM FULLをかけると解決するあたり、統計情報ではなくAUTO VACUUMで行われる通常のVACUUMでは回収できない死にタプルの多さによる性能劣化と見るべきか・・・
正解だか不正解だかはよくわからん。
ほんとによくわからん、未来のyamamotodin君、引き続きよろしく頼む。
補遺
運用中のDBにホイホイとロックが必要なVACUUM FULLかけられんのだよ。