縦軸が分（minutes）、横軸がテーブルのレコード数です。
| Table count | minutes |
| 25000 | 1 |
| 130000 | 1 |
| 41000000 | 7 |
| 400000000 | 65 |
| 670000000 | 210 |
| 2600000000 | 730 |
| 3000000000 | 1200 |
| 4800000000 | 4680 |
Amazon Redshiftのインスタンスタイプはds1.xlargeです。
数億分のデータをためた場合、どのくらいの時間でバキュームできるかを測ってみました。
バキューム実行コマンドは VACUUM FULL table_name; です。
（実際に使っているテーブルにバキュームをかけようとしているので、継続的にデータのインサートを行いながらの計測になります。そのためどんな環境で行っても同じ結果になるわけではないとおもいます。その点注意をお願いします。）
結果、1億程度ならば数分でバキューム完了しますが、10億を超えたあたりから実行時間が伸び、30億を超えるとほぼ1日がかりという時間が必要になりました。
まとめ
レコード数が大量になるにつれてバキューム実行時間が増えることがわかりました。
今回のバキューム中にはAmazon Redshiftのレスポンスが悪くなる現象は、とくにみられませんでした（すごい）、ですが、更に大量のデータを扱うときにはどうなるかわかりません。あらかじめテストしておくと良いでしょう。
すぐに数億のデータが溜まるようなテーブルを扱うときには。月ごと、日ごとのテーブルを用意して一つ一つのテーブルのサイズを小さく保つという運用をしたほうが、より少ない時間でバキュームができるので、パフォーマンスを維持できるとおもいます。
参考文献
テーブルのバキューム処理 - Amazon Redshift
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/t_Reclaiming_storage_space202.html
VACUUM - Amazon Redshift
http://docs.aws.amazon.com/ja_jp/redshift/latest/dg/r_VACUUM_command.html
Analyzeの必要性とvacuumの落とし穴
http://www.slideshare.net/motonobufukao/analyzevacuum
Amazon Redshift Useful SQL: VACUUM処理が必要なテーブルを洗い出す ｜ Developers.IO
http://dev.classmethod.jp/cloud/aws/amazon-redshift-useful-sql-require-tables-to-vacuum/
