« マジックナンバーへの対処法 | トップページ | autovacuum関連のパラメータ設定 »

2014.02.02

Fillfactorの設定値

PostgreSQLはVer8くらいからだったかHOT(Heep Only Tuple)更新という機能が加わっている。
これがなかった時代にはMVCC型であるがゆえに
「更新つどのオーバーヘッドが大きい=更新性能が悪い」
というような評判がついてまわったものだ。

でHOTの詳しいメカニズムなどはLet'sPostgresとかに譲るとして、最近決めたFillfactor設定基準について。

そもそもFillfactorを設定すべきテーブルが何であるのかをちょっとだけ考えてみた。
とあるプロジェクトでは「Fillfactorは必ず90で設定するように」という規約があった。
Let's Postgresの記事からしても、まあ90%くらいが妥当だ、という記述があり、これをそのまま転用していたようだ。
90%という数値については私もおおむね適切だと思う。
fillfactorは1ページブロック当たりでHOT用の領域をどのくらい準備するのか、というのかということなので単純にこの値を大きくしていくと1ページ当たりの有効な実データ領域が減ってしまい、データベースの肥大化とともにSELECT処理などの性能を落してしまう。

HOT更新が効果を発揮するのは「インデックスの更新を伴わない更新処理」という動作についてである。
このため次のような性格を持つテーブルについてはfillfactorはデフォルト(100%)のままで運用した方が効率が良さそうだ。


  1. SELECT/INSERT処理しかされないような履歴系テーブル
  2. インデックスがたくさん張られているテーブル

1番は言うまでもなく、CRUD上でUpdate処理が存在しないようなテーブル。業務システムではけっこうあるんではないだろうか? ログファイルをテーブルで保存する場合などもこうしたテーブルが該当するだろう。
そもそもUPDATE処理が登場しないのであれば、HOTのための余剰領域はオーバーヘッドになるだけだ・
2番は微妙。
というか2番のようなテーブルについてはfillfactorを考える前にインデックスそのものを見直した方がいいだろう。
pg_stat_user_indexesを使えば、使用されていないインデックスが抽出できるので、無駄に張られていて使われてないインデックスは削除し、その上で適切なfillfactorなのか見ていくべきだろう。

とはいえ、私自身が扱ってるプロジェクトではSELECT性能を優先して値の変動の多いカラムにインデックスをはることがあるので、そういう性質のテーブルの場合はHOT更新はあきらめるしかないだろう。

HOTが有効利用されているかどうかはpg_stat_user_tablesを使うことでn_tup_upd(更新されたた行数)とn_tup_hot_upd(HOT更新された行数)を調べられるので、この比が著しく大きい場合はHOTが利用されていないと言うことになるので、インデクスの見直しやfillfactorの見直しの対象とすることになるだろう。

あ、真面目に書いちゃった(^^;

|

« マジックナンバーへの対処法 | トップページ | autovacuum関連のパラメータ設定 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/2022/59057096

この記事へのトラックバック一覧です: Fillfactorの設定値:

« マジックナンバーへの対処法 | トップページ | autovacuum関連のパラメータ設定 »