web-dev-qa-db-ja.com

DELETEまたはTRUNCATEを使用してディスク領域を解放しますか？

1週間以上前、postgresqlテーブルのすべての行を削除しました（truncateではなく_delete from ..._を使用）。 Select count (*)は、テーブルの行が0であることを示します。

queries を実行してディスク領域をクエリしても、テーブルが領域を占有しているのがわかります。具体的には、すべてのインデックスがまだ存在し、スペースを占有しています。それらを削除してディスク容量を解放するにはどうすればよいですか？次に、すべての行を削除しても、なぜ最初の場所に留まるのですか？

必要に応じて、表の詳細な説明を次に示します。

_                                      Table "public.links_photoobjectsubscription"
     Column     |           Type           |                                 Modifiers                                  
----------------+--------------------------+----------------------------------------------------------------------------
 id             | integer                  | not null default nextval('links_photoobjectsubscription_id_seq'::regclass)
 viewer_id      | integer                  | not null
 updated_at     | timestamp with time zone | not null
 seen           | boolean                  | not null
 type_of_object | character varying(15)    | not null
 which_photo_id | integer                  | 
 which_link_id  | integer                  | 
 which_group_id | integer                  | 
 which_salat_id | integer                  | 
Indexes:
    "links_photoobjectsubscription_pkey" PRIMARY KEY, btree (id)
    "links_photoobjectsubscription_seen" btree (seen)
    "links_photoobjectsubscription_updated_at" btree (updated_at)
    "links_photoobjectsubscription_viewer_id" btree (viewer_id)
    "links_photoobjectsubscription_which_photo_id" btree (which_photo_id)
Foreign-key constraints:
    "links_photoobjectsubscription_viewer_id_fkey" FOREIGN KEY (viewer_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED
    "links_photoobjectsubscription_which_photo_id_fkey" FOREIGN KEY (which_photo_id) REFERENCES links_photo(id) DEFERRABLE INITIALLY DEFERRED
    "which_group_id_photoobjectsubscription" FOREIGN KEY (which_group_id) REFERENCES links_group(id) ON DELETE CASCADE
    "which_link_id_photoobjectsubscription" FOREIGN KEY (which_link_id) REFERENCES links_link(id) ON DELETE CASCADE
    "which_salat_id_photoobjectsubscription" FOREIGN KEY (which_salat_id) REFERENCES links_salatinvite(id) ON DELETE CASCADE
_
postgresqldeletetruncate
4
Hassan Baig

VACUUMのドキュメントから

VACUUMには、標準のVACUUMとVACUUM FULLの2つのバリアントがあります。 VACUUM FULLは、より多くのディスク領域を再利用できますが、実行速度ははるかに遅くなります。また、VACUUMの標準形式は、本番データベースの操作と並行して実行できます。 （バキュームされている間、ALTER TABLEなどのコマンドを使用してテーブルの定義を変更することはできませんが、SELECT、INSERT、UPDATE、DELETEなどのコマンドは引き続き正常に機能します。）VACUUM FULLは排他ロックをオンにする必要があります作業中のテーブルであるため、テーブルの他の使用と並行して実行することはできません。したがって、一般に、管理者は標準のVACUUMを使用し、VACUUM FULLを回避するように努めるべきです。

基本的に、（同じドキュメントから）テーブル全体を書き換えるコマンドを発行する必要があります。

ヒント：大量の更新または削除アクティビティの結果としてテーブルに多数の無効な行バージョンが含まれている場合、プレーンなVACUUMでは不十分な場合があります。そのようなテーブルがあり、テーブルが占有する余分なディスク領域を再利用する必要がある場合は、VACUUM FULL、またはCLUSTERまたはALTER TABLEのテーブル書き換えバリアントのいずれかを使用する必要があります。これらのコマンドは、テーブルの新しいコピー全体を書き換え、新しいインデックスを作成します。これらすべてのオプションには、排他ロックが必要です。また、テーブルとインデックスの古いコピーは新しいものが完了するまで解放できないため、テーブルのサイズとほぼ同じ追加のディスク領域を一時的に使用することに注意してください。

同じドキュメントで、

ヒント：内容全体が定期的に削除されるテーブルがある場合は、DELETEに続いてVACUUMを使用するのではなく、TRUNCATEを使用することを検討してください。 TRUNCATEは、現在使用されていないディスク領域を再利用するために後続のVACUUMまたはVACUUM FULLを必要とせずに、テーブルのコンテンツ全体をすぐに削除します。短所は 厳密なMVCCセマンティクスに違反する 。です。

そして、 TRUNCATE のドキュメントから

TRUNCATEは、一連のテーブルからすべての行をすばやく削除します。これは、各テーブルの非修飾DELETEと同じ効果がありますが、実際にはテーブルをスキャンしないため、高速です。 さらに、後続のVACUUM操作を必要とせずに、すぐにディスク領域を再利用します。これは大きなテーブルで最も役立ちます。

7
Evan Carroll