私は奇妙な問題があります。私のpostgresql（8.3）のサイズが増えています。だから私はダンプを作ってから、データベースをきれいにしてからダンプを再インポートしました。データベースのサイズは約50％削減されました。PostgreSQLデータベースのサイズが増加しています
いくつかの情報： （1）AUTOVACUUMとREINDEXはバックグラウンドで定期的に実行されています。 （2）データベースエンコーディングはASCIIです。 （3）データベースの場所：/ database/pgsql/data （4）システム：Suse-Ent。 10.
任意のヒントは、あなたの特定のセットアップの詳細については詳細を知らなくても
デッドタプルがmax_fsm_pagesで説明されている値を超えて積み重なった場合、通常のVACUUMはすべてを解放することはできません。最終的な結果として、デッドスペースが累積し続けるため、データベースは時間の経過とともに大きくなります。 VACUUM FULLを実行するとこの問題が解決されます。残念ながら、大規模なデータベースでは非常に長い時間がかかります。
この問題が頻繁に発生している場合は、さらに頻繁に空吸引する必要があります（自動真空が役立ちます）。またはmax_fsm_pagesの設定を増やしてください。 VACUUM VERBOSEを実行すると、解放されたページの数が表示され、max_fsm_pagesを超えた場合に警告が表示されます。これは、この値を決定するのに役立ちます。詳細については、マニュアルを参照してください。 http://www.postgresql.org/docs/8.3/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-FSM
幸いにも、8.4の可視性マップはこの問題を解決します。 Despeszさんはいつものようにテーマについて素晴らしい話をしています：http://www.depesz.com/index.php/2008/12/08/waiting-for-84-visibility-maps/
VACUUM FULLは役に立ちます – stanleyxu2005
を高く評価されている、物事のカップルが気にしています。 AUTOVACUUMが実行されているときに、ディスク領域を再利用しようとしていますか？それがサーバーログを介していることを確認できますか？
第2に、特に以前の回答が「いいえ」だった場合は、AUTOVACUUMの値が正しくない可能性があります。私は主題に関して次のことを読むことを強く勧めます：http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html#AUTOVACUUM
実行中の再索引は必要ありません。
冗長でデータベース全体を実行し、fsm設定の最後の行を確認してください。ヒント - おそらく間違っています。
VACUUM FULLも試しましたか？ （警告、それはあなたのデータベースを長時間ロックします）。AUTOVACUUMがとても熱心であるとは確信していません。
まだ実行されていない場合は、長時間実行されていないアイドル状態のトランザクションを確認してください。 VACUUM（手動と自動の両方）がスペースを空けないようにします。
私はserverfault.comでこれをお勧めします。 – Elijah