タグ付けされた質問 「vacuum」

Mac（10.10.4）でpostgres（postgis）9.4.2を実行しています。 私はいくつかの大きなテーブル（数TB）を持っています。 そのうちの1つで約1週間かかるインデックス作成中に、停電がバッテリーユニットとシステムよりも長く続いたときにインデックスが終了するポイントに近いと予想されるので、利用可能なHDスペースの低下を観察しました降りた。fillfactor=100静的データソースであるため、私はバッファをオフにしていて、ビルド中にそれを行いました。再起動時に、ドライブに残っている使用可能なスペースは、インデックスビルドのほぼ終了時とまったく同じです。真空分析はスペースを解放しません。 テーブルを落として再度取り込みましたが、スペースは落ちませんでした。現在、インデックスを作成するための十分なスペースがない場所にいます。 インデックスの構築中に生成されたファイルは、停電中にマシンがダウンした方法が原因でシステムによって削除できない場所でスタックしていますか？ テーブルサイズとデータベース内のインデックス（そのドライブ上の唯一のデータ）を見ると、合計で約6TBです。ドライブです8TB未満、そこにある500ギガバイトは、インデックスがあったであろうという大きさです1.5TB失われたどこかに約あるようですので、ドライブに残しました。 何か案は？

9 postgresql  index  postgresql-9.4  disk-space  vacuum 

VACUUM ANALYZE VERBOSE大きなテーブルに大きなDELETE/INSERT変更を加えた後、いくつかの大きなテーブルで「手動」を実行します。これは問題なく機能しているように見えますが、テーブルのVACUUMジョブが数時間実行されることがあります（同様の問題と理由については、この投稿を参照してください）。 さらに調査を行ったところ、実行後でも、多数のデッドタプルを持つ大きなテーブルがあることがわかりましたVACUUM。たとえば、このレスポンスのクエリから生成された統計の一部を次に示します。 -[ RECORD 50 ]--+--------------------------- relname | example_a last_vacuum | 2014-09-23 01:43 last_autovacuum | 2014-08-01 01:19 n_tup | 199,169,568 dead_tup | 111,048,906 av_threshold | 39,833,964 expect_av | * -[ RECORD 51 ]--+--------------------------- relname | example_b last_vacuum | 2014-09-23 01:48 last_autovacuum | 2014-08-30 12:40 n_tup | 216,596,624 dead_tup …

8 postgresql  postgresql-9.3  vacuum