Yeah, true. Even though Redshift is based on Postgres, it does not leverage the automatic vacuuming facility of postgres. So the vacuuming of tables to recover

Yeah, true. Even though Redshift is based on Postgres, it does not leverage the automatic vacuuming facility of postgres. So the vacuuming of tables to recover disk space from deleted rows needs to be done manually. There are 3 types of vacuuming in Redshift (DELETE ONLY, SORT, REINDEX). The vacuum SORT operation is done on tables that have a sort key. To the extent that a vacuum SORT is an expensive (high IO) operation, we recommend when possible, to avoid the need to vacuum by loading the rows in sort order. If you do that, you will not need to vacuum the table, and this is the optimal solution for very long tables. When dealing with a very long table (>10b rows) that has a sort key, it’s useful to partition the table into multiple tables where the table names are modified to indicate the partition. This is useful when pruning the size of the table, you don’t have to run VACUUM DELETE ONLY. The key is to vacuum on a regular basis, and keep your stats off below 10%. If you wait too long, you might end up in a place where you have to resize your cluster or do a deep copy. One more thing: Run your vacuum jobs in the queue with the most memory.