は、私は3つのテーブルでのPostgreSQL 9.2のデータベースを持っていた

Question

パフォーマンスが向上しません私のメインデータベースをスピードアップするためにデータを2番目のデータベースに転送します（より少ないデータ=より良いパフォーマンス）。

すべてのテーブルから約20％のデータを移行した後、私のメインデータベーステーブルでVACUUM ANALYZEを少しだけクリーンアップしました。

私は次の20％が移行するのがずっと速くなると思っていました....私は間違っていました。アーカイブするデータの次のすべてのパーセンテージは、処理速度が遅く、遅くなります。

私はおそらくVAACUM FULLが必要だと思っていましたが、それを読むのはお勧めできません。さらに、クエリが非常に遅く、ディスク容量がほぼ2倍必要です（新しいテーブルを作成して古いテーブルを削除します）。

データが少なくても処理が遅くなる理由は何ですか？マイグレーション後にデータベースの速度を上げることができるいくつかのステップがありませんか？それ以外のクリーンアップのいくつかの種類VACUUM ANALYZE

メインデータベースからコピーするデータを選択し、メインデータベースから削除するデータを選択する3つのステップを測定の測定時間があることを指定する必要があります。

データの選択は問題です。アーカイブプロセスについて

：

1. 私はX日後、古いテーブル行を選択します。それをコピーしてから削除します。
2. 次に、前に選択したA行に接続されたB行を選択します。それをコピーしてから削除します。
3. 最後に選択したB行に接続されたC行を選択します。それをコピーしてから削除します。

コンファレンス：

8ギガバイトのRAM。

max_connections = 100 
shared_buffers = 2GB 
effective_cache_size = 6GB 
work_mem = 32MB 
maintenance_work_mem = 512MB 
checkpoint_segments = 32 
checkpoint_completion_target = 0.9 
wal_buffers = 16MB 
default_statistics_target = 100 
random_page_cost = 2.0 

Answer 1

時間がどこで費やされているかを調べてみてください。 BとCの行を見つけるのはSELECTですか？それはDELETEですか？

問題のある文が見つかったら、EXPLAIN (ANALYZE)の出力を見てください。それはあなたが時間が費やされたことを伝えます。

テーブルから行を削除しても、テーブルが小さくなるわけではなく、必ずしもテーブルのクエリが高速になるわけではありません。 のヘルプは、特に逐次スキャンがある場合はVACUUM (FULL)となります。 すべてデータベースにテーブルを実行する必要はありません。スペースが問題であれば、別のテーブルの後でそれを調整することができます。
まず、実行計画を見て、それがまったく役立つかどうかを確認してください。