フラグメンテーションと vacuum

どこかしら間違ってる気がするけど、とりあえずメモ書き。

postgresql を使ってるとデータベースが肥大化し、おまけにだんだんとファイルシステムからの影響を受ける様になるみたいです。ファイルシステムのデータが断片化するフラグメンテーションが起きると、もろに postgresql のパフォーマンスが影響受けるみたい。特に vacuum の処理。

どーも、アップデートをするたびに postgresql は上書きをせず、つまり古いデータを消さず、新しい領域にデータを入れて行く方法みたい。んで、データを削除すると、ゴミが残った虫喰い穴状態になってしまう気配。参考：PostgreSQL アーキテクチャ解説 ストレージ入出力(PDFファイル)

そんな訳で、ゴミを取り除く作業が Vacuum。そのまんまじゃんと思うけど、結構必要な作業。特に、Delete文をよく発行する場合は。

以下、vacuumコマンドの使用例

vacuumdb [connection-options...] [--full | -f] [--verbose | -v] [--analyze | -z] [--table | -t 'table  [( column [,...] )]' ] [dbname]
vacuumdb [connection-options...] [--all | -a] [--full | -f] [--verbose | -v] [--analyze | -z]
-z 統計情報を出力
-v 処理実行中に詳細な情報を表示します。

参考：http://www.postgresql.jp/document/pg734doc/reference/app-vacuumdb.html

[top: ~][23:11] $ vacuumdb -v -z -U postgres news_db
INFO:  vacuuming "information_schema.sql_sizing"
INFO:  "sql_sizing": found 0 removable, 23 nonremovable row versions in 1 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 9 unused item pointers.
1 pages contain useful free space.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
....
INFO:  analyzing "public.websiteword"
INFO:  "websiteword": scanned 0 of 0 pages, containing 0 live rows and 0 dead rows; 0 rows in sample, 0 estimated total rows
INFO:  free space map contains 1664 pages in 76 relations
DETAIL:  A total of 2784 page slots are in use (including overhead).
2784 page slots are required to track all free space.
Current limits are:  20000 page slots, 1000 relations, using 182 kB.
VACUUM
[top: ~][23:16] $ 

参考：http://ml.postgresql.jp/pipermail/pgsql-jp/2005-November/019888.html