Dan wrote: > I was under the impression that a full vacuum was more extensive and > compacted the tables more than a regular vacuum.
That much is true, full vacuum is more extensive. It's also slower, and requires locking. The difference being that the full variant actually compacts the data, whereas the "lazy" variant merely marks the unused data space for re-use. Realistically a full vacuum shouldn't be needed in SA applications. It also shouldn't be needed very frequently in other applications if normal vacuuming has been run frequently. In a SpamAssassin 3.0.0 or higher bayes DB there's going to be a lot of motion (ie: lots of records in and out) and records are all of equal size. When a lazy vacuum marks the data space as available for re-use, new tokens should, theoretically, fall into the old space without any excessive fragmentation. If the records were all of different sizes, fragmentation might eventually be a problem and require a full vacuum, but SA's bayes records are all fixed-length since the data is a sha1 hash. A vacant space in the database will always be an exact fit for a new token. The postgresql website has a really good article on the use of the two: http://www.postgresql.org/docs/8.1/interactive/maintenance.html#VACUUM-FOR-SPACE-RECOVERY Including this very pointed quote: "Moderately frequent standard VACUUM runs are a better approach than infrequent VACUUM FULL runs for maintaining heavily-updated tables. "
