IDで数百万行を削除する最良の方法

それはすべて異なります...

同時書き込みアクセスがないと仮定 関係するテーブルに移動するか、テーブルを排他的にロックする必要がある場合があります。そうしないと、このルートがまったく役に立たない場合があります。
すべてのインデックスを削除します（削除自体に必要なインデックスを除く）。
後で再作成します。これは通常、インデックスの増分更新よりもはるかに高速です。
安全に削除/一時的に無効にできるトリガーがあるかどうかを確認します。
外部キーはテーブルを参照しますか？それらを削除できますか？一時的に削除しましたか？
自動真空設定によっては、 VACUUM ANALYZEの実行に役立ちます手術前。
マニュアルの関連する章に記載されているポイントのいくつかデータベースへの入力 設定によっては、役立つ場合もあります。
テーブルの大部分を削除し、残りをRAMに収める場合、最も速くて簡単な方法は次のとおりです。

BEGIN; -- typically faster and safer wrapped in a single transaction

SET LOCAL temp_buffers = '1000MB'; -- enough to hold the temp table

CREATE TEMP TABLE tmp AS
SELECT t.*
FROM   tbl t
LEFT   JOIN del_list d USING (id)
WHERE  d.id IS NULL;      -- copy surviving rows into temporary table

TRUNCATE tbl;             -- empty table - truncate is very fast for big tables

INSERT INTO tbl
SELECT * FROM tmp;        -- insert back surviving rows.
-- ORDER BY ?             -- optionally order favorably while being at it

COMMIT;

このようにして、ビュー、外部キー、またはその他の依存オブジェクトを再作成する必要はありません。そして、膨らみのない手付かずの（ソートされた）テーブルを手に入れることができます。

temp_buffersについて読むマニュアルの設定。この方法は、テーブルがメモリ、または少なくともそのほとんどに収まる限り高速です。トランザクションラッパーは、この操作の途中でサーバーがクラッシュした場合にデータが失われるのを防ぎます。

VACUUM ANALYZEを実行しますその後。またはVACUUM FULL ANALYZE 最小サイズにしたい場合（専用ロックがかかります）。大きなテーブルの場合は、代替案CLUSTERを検討してください。 / pg_repack または同様のもの：

Postgresタイムスタンプクエリ範囲を最適化する

小さなテーブルの場合、単純なDELETE TRUNCATEの代わりに多くの場合、より高速です：

DELETE FROM tbl t
USING  del_list d
WHERE  t.id = d.id;

読むメモ TRUNCATEのセクションマニュアルで。特に（ペドロも彼のコメントで指摘したように）：

TRUNCATE 同じコマンドでそのようなすべてのテーブルも切り捨てられない限り、他のテーブルからの外部キー参照があるテーブルでは使用できません。 [...]

そして：

TRUNCATE ON DELETEは起動しませんテーブルに存在する可能性のあるトリガー。