ディスクスペースをオペレーティングシステムに戻すVACUUM

VACUUM通常、特別な場合を除いて、オペレーティングシステムにディスク領域を返しません。
ドキュメントから：

標準形式でVACUUMは、テーブルとインデックス内の無効な行バージョンを削除し、将来の再利用に使用可能なスペースをマークします。ただし、テーブルの最後の1つ以上のページが完全に空になり、排他的なテーブルロックを簡単に取得できる特別な場合を除いて、オペレーティングシステムに領域を返しません。対照的に、VACUUM FULLデッドスペースのない完全に新しいバージョンのテーブルファイルを書き込むことにより、アクティブにテーブルを圧縮します。これにより、テーブルのサイズが最小になりますが、時間がかかる場合があります。また、操作が完了するまで、テーブルの新しいコピー用に追加のディスク領域が必要です。

問題は、このデータベースの状態をどのone or more pages at the end of a table become entirely freeように達成できるかということです。これはを介して行うことができますがVACUUM FULL、実装するのに十分なスペースがありません。他の可能性はありますか？

OSにスペースを戻すには、を使用しますVACUUM FULL。その間、あなたは走ると思いますVACUUM FULL ANALYZE。私はマニュアルを引用します：

FULL

「フル」バキュームを選択します。これにより、より多くのスペースを再利用できますが、時間がかかり、テーブルが排他的にロックされます。この方法では、テーブルの新しいコピーを書き込み、操作が完了するまで古いコピーを解放しないため、追加のディスク領域も必要です。通常、これは、テーブル内から大量のスペースを再利用する必要がある場合にのみ使用してください。

大胆な強調鉱山。

CLUSTER 副次的効果としてもそれを達成します。

VACUUM通常、Plain は目標を達成しません（「テーブルの最後にある1つ以上のページが完全に無料」）。行を並べ替えることはせず、機会が生じたときにファイルの物理的な終わりから空のページをプルーニングするだけです-マニュアルからの引用のように。

他のタプルが追加される前INSERTに行とバッチのバッチを作成すると、物理ファイルの最後に空のページをDELETE取得できます。または、十分な行が削除された場合、偶然に発生する可能性があります。

VACUUM FULLスペースの再利用を妨げる可能性のある特別な設定もあります。見る：

• 非常に高頻度の更新のためにテーブルを最適化する方法は？

テスト用に表の最後に空のページを準備します

システム列ctidは、行の物理的な位置を表します。その列を理解する必要があります：

• ctidをページ番号と行番号に分解するにはどうすればよいですか？

それを使って、最後のページからすべての行を削除してテーブルを準備できます。

DELETE FROM tbl t
USING (
   SELECT (split_part(ctid::text, ',', 1) || ',0)')::tid     AS min_tid
        , (split_part(ctid::text, ',', 1) || ',65535)')::tid AS max_tid
   FROM   tbl
   ORDER  BY ctid DESC
   LIMIT  1
   ) d
WHERE t.ctid BETWEEN d.min_tid AND d.max_tid;

現在、最後のページは空です。これは同時書き込みを無視します。そのテーブルに書き込みを行うのは自分だけであるか、干渉を避けるために書き込みロックを取得する必要があります。

クエリは、適格な行をすばやく識別するために最適化されます。aの2番目の数値は、tidunsignedとして格納されているタプルインデックスint2であり65535、そのタイプの最大値（2^16 - 1）であるため、これが安全な上限です。

SQL Fiddle（異なるケースの単純なテーブルを再利用します。）

行/テーブルのサイズを測定するツール：

• PostgreSQLテーブルの行のサイズを測定する

ディスクがいっぱいです

これらの操作のいずれかを行うには、ディスク上にウィグルルームが必要です。/のpg_repack代わりとしてのコミュニティツールもあります。排他ロックを回避しますが、同様に機能するために空き領域が必要です。マニュアル：VACUUM FULLCLUSTER

ターゲットテーブルとインデックスの2倍の空きディスク領域が必要です。

最後の手段として、ダンプ/復元サイクルを実行できます。これにより、テーブルとインデックスからすべての膨張も削除されます。密接に関連した質問：

• 空きディスク容量なしでVACUUM FULLを実行する必要があります

向こうの答えはかなり急進的です。状況が許す場合（外部キーや行の削除を妨げる他の参照がなく、テーブルへの同時アクセスがない場合）、次のことができます。

接続ディスクへのテーブルダンプリモートコンピュータとディスクスペースの多くを（-a用--data-only）：

リモートシェルから、テーブルデータをダンプします。

pg_dump -h <host_name> -p <port> -t mytbl -a mydb > db_mytbl.sql

pgセッションでTRUNCATEは、テーブルは次のようになります。

-- drop all indexes and constraints here for best performance
TRUNCATE mytbl;

リモートシェルから、同じテーブルに復元します。

psql -h <host_name> -p <port> mydb -f db_mytbl.sql
-- recreate all indexes and constraints here

現在、デッド行や膨張はありません。

しかし、おそらくあなたはそれをよりシンプルにすることができますか？

• 無関係なファイルを削除（移動）して、ディスクに十分なスペースを確保できますか？

• VACUUM FULLテーブルを1つずつ小さくして、十分なディスク領域を解放できますか？

• 肥大化したインデックスからディスク領域を実行REINDEX TABLEまたはREINDEX INDEX解放できますか？

あなたが何をするにしても、発疹にならないでください。疑わしい場合は、最初にすべてを安全な場所にバックアップしてください。