PostgreSQL 8.4でインデックスを再作成する前に、常にVACUUM ANALYZEを行う必要がありますか？

毎日早朝にpgAgentジョブがPostgreSQL 8.4データベースのテーブルBからテーブルAの内容を更新します。テーブルAには、91列にまたがる約140kのレコードが含まれ、2つのインデックスがあります。1つはPRIMARY KEYの一部として、もう1つはPOINT PostGISジオメトリ列のGISTインデックスです。

プロセスを少し速くするために、ジョブはテーブルAのレコードを削除してテーブルBからレコードを挿入する前に、ジオメトリ列のインデックスを削除し、その後インデックスを再作成します。これがすべて完了すると、autovacuumデーモンは、希望どおりに動作するようになります（ジョブの統計情報とテーブルの統計情報をジョブの完了時間とautovacuumの実行時間と比較して10分ほど後）。

これがすべて起こった後の今朝のテーブルのチェック時に、テーブルの統計から、テーブルサイズは272MB、TOASTテーブルサイズは8192バイト、インデックスサイズは23MBであることがわかりました。これはかなり大きいように見えたので、テーブルにREINDEXコマンドを発行し、インデックスサイズは9832kBになりました。

私の質問はこれです：

インデックス（または少なくともジオメトリ列インデックス）を最初から作成したときに、REINDEXがインデックスのサイズを大幅に削減するのはなぜですか？インデックスが作成される前に、テーブルがバキューム/分析されていることを確認する必要がありますか？主キーのインデックスを削除することがこれの要因ではありませんか？何が欠けていますか？

CREATE INDEXステートメントで、別のセッションがアクティブなスナップショットを保持していることを確認した場合でも、削除されたレコードに関心がある可能性がある場合は、それらの削除されたレコードを新しいインデックスに含めます。

同様に、REINDEXは、別のセッションがアクティブなスナップショットを保持していることを検出した場合でも、削除されたレコードに関心がある可能性がある場合、それらの削除されたレコードを新しいインデックスに含めます。

VACUUMが、別のセッションがアクティブなスナップショットを保持していることを確認した場合でも、削除されたレコードに関心がある可能性がある場合、それらのレコードはテーブルに保持されます。そして、スナップショットがまだ存在する限り、REINDEXまたはCREATE INDEXもそれらを新しいインデックスに含める必要があります。

削除された行を表示できる可能性のあるスナップショットが存在するか、もはや存在しない場合、VACUUMはそれらをテーブルから削除する場合があります。しかし、CREATE INDEXまたはREINDEXは、VACUUMがそれらを有能なオブジェクトから削除するために移動していたかどうかに関係なく、それらを新しいインデックスに持ち越さないこともできます。

したがって、あなたのシナリオでは、最初のCREATE INDEXとREINDEXの間のVACUUMの役割はおそらく時間がかかるだけです。

さまざまな順序で試してみた結果、おそらく、空にされていないスペースがインデックスに追加されるため（削除されたレコードのインデックス？）、REINDEX命令の前にVACUUMを実行することが唯一の方法であると思われます。を使用してテーブルを強制的に書き換える

ALTER TABLE blah ALTER COLUMN whiffle SET DATA TYPE whiffle_type;

使われなくなったスペースを空にするので、同じようなことをします。

プロセスの途中でVACUUMを実行する必要がある場合、トランザクションの外部でVACUUMコマンドを発行する必要があるため、フローが少し中断されます。