VACUUMについて
PostgreSQLの定期的な保守作業の中に、バキューム処理があります。保守作業といっても、定期的に手動で何かをするわけではなく、自動バキュームデーモン（autovacuum launcher）を起動しておくと自動でバキューム処理を行ってくれます。手動でVACUUMコマンドを実行して流すこともできますが、たいていの運用では自動で行います。デフォルトでは自動バキュームデーモンが起動されるようになっています。PostgreSQLのプロセスを確認すると起動されていることが確認できます。
>ps auxww | grep ^post
自動バキュームデーモンが実行されるタイミングは任意となっています。定期的に１日１回決まった時間に実行されるような動きではありません。
自動バキュームデーモンがデータベースの更新頻度に応じて、動的にバキューム作業を計画して実行してくれます。
データベースへの更新/削除が激しいときは、頻繁にバキュームが流れ、大した量ではないときはお休みしているといった動きになります。
バキュームを動的な処理に任せておくのではなく、１日１回決まった時間に流すようにすることもできます。そうしたい場合は、自動バキュームデーモンをストップさせて、OSの機能を使って、cronでVACUUMコマンドをスケジュールさせることになります。
どっちがいいのかについては、自動バキュームデーモンが実行される頻度によって判断することになるかと思います。VACUUMの心配をするくらいなら、ハードディスクの容量に余裕をもたせておいた方が賢明でしょう。
VACUUMの種類
VACUUMには標準VACUUMとVACUUM FULLと２つの種類が存在しています。
大抵の運用の場合、標準VACUUMを実行します。VACUUM FULLはよほどのことがない限り実行されることはありません。標準VACUUMは実行されていても、SELECT、INSERT、UPDATE、DELETEといったSQLコマンドを通常通りに流すことができます。それが、VACUUM FULLだとACCESS EXCLUSIVEロックをかけるため、上記のSQLコマンドが実行できなくなります。業務時間中は絶対にVACUUM FULLを実行してはいけません。さらに、VACUUM FULLは大量のI/Oトラフィックを発生させるため、データベースへのセッションに影響が出る可能性があると言われています。つまり、データベースへ接続できなくなる可能性があるということです。恐ろしいことです。
デフォルトで実行される自動バキュームデーモンは、標準VACUUMが実行されます。VACUUM FULLではありません。ご安心を。どうしてもVACUUM FULLを実行したい場合は手動で実行することになります。
標準VACUUMは不要になった領域を削除した後、増えた領域をOSに返却することはしません。またいずれ再利用されるために残しておきます。それに比べ、VACUUM FULLは極限まで領域を削除して最小化させた後、増えた領域をOSに返却します。
極端なまでにデータベースの無駄領域が肥大化して、OSの容量に影響が出てくるような事態になったときに、急場しのぎで実行されるのがVACUUM FULLということになりそうです。一時的に大量データの更新、削除を行ったような場合に限り、VACUUM FULLをする意義はあるでしょう。
おまけ
テーブルを削除するとき、DELETEとTRUNCATEを使い分けることがあります。TRUNCATEは厳密にいえば削除ではなく切り捨てです。TRUNCATEをするとデータベースに無駄領域を残すことがありません。つまり、TRUNCATEを行った場合はVACUUMをする必要がないということです。ワークファイルの削除はDELETEではなくTRUNCATEを利用されるかと思いますが、つまり、こういうことです。