Amazon Redshiftで論理削除状態のテーブルを手早く物理削除できないか(VACUUM DELETEにより解決しなかった)

Question

前提・実現したいこと

バッチ処理でAWS Redshiftのupdate文を活用するため、短時間で終わる方法で論理削除されたレコードを処理したいです。(1.0.5290のupdateで追加された自動VACUUM DELETEで済む想定だった)

試したこと、想定、結果

下調べした結果として論理削除されたレコードが少ないとVACUUMはあまり意味がない事もあるという事だったので、COUNT(*)で返ってくるレコード数 / STL_VACUUM のrowsの値が92%ほどの状態で各種VACUUMを試したところ、期待していた効果が得られませんでした。

VACUUM DELETE ONLY(手動、オート)

想定

• SVV_TABLE_INFO.tbl_rowsがレコード数に近づく。
• SVV_TABLE_INFO.sizeが減る。
• 動作が軽い。

結果

• SVV_TABLE_INFO.tbl_rowsの値に変化がなかった。
• SVV_TABLE_INFO.sizeが減らなかった。
• 確かに数秒～１分程度で終わったが何が変化したかわからない。

VACUUM REINDEX

想定

• SVV_TABLE_INFO.tbl_rowsがレコード数に近づく。
• SVV_TABLE_INFO.sizeが減る。
• STL_VACUUM.sortedrowsはcount(*)の結果になる。
• 動作が重い。

結果

• SVV_TABLE_INFO.tbl_rowsの値に変化がなかった。
• SVV_TABLE_INFO.sizeが減った。
• STL_VACUUM.sortedrowsはSVV_TABLE_INFO.tbl_rowsと同じ値になった。
• １回の実行で実用に耐えない時間がかかった。

知りたいこと

• updateによって論理削除状態になったrowはVACUUMの対象にならないのか。対象にする方法。
• sizeが減っている事とtbl_rowsが減っていない事のどちらを気にするべきか。tbl_rowsは減らなくて問題ないのか。
• 上記でsizeが減っていればokであってもVACUUM REINDEXでは時間がかかる。何か他の手段はないか。
• 別のテーブルで実施すると上記の結果とはまた異なって変化がない事もあった。何か阻害するような要素があるのか。

これ以外でも何かご存知のことがありましたらご助言ください。

補足情報（FW/ツールのバージョンなど）

PostgreSQL 8.0.2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3), Redshift 1.0.7562

Answer 1

先週頃からAUTO_VACUUMで正常に拾われるようになり、自然解決しました。AWSのサイレントupdate的な形でしょうか。