Our database has fast rate of transactions. I did think, that such rate is impossible, until I've seen it with my eyes. I've been instinctively insisting on fixing code to reduce number of transactions (sometimes successful), but never checked what are consequences for database.
One of consequences is fast rate of autovacuum VACUUM FREEZE.
VACUUM is essential for Postgresql to mark non-visible rows (those which were normal rows, but became invisible because of update or delete) as visible to PG. Note, that they become visible only to PG, previously PG didn't know they are free for use, and thus had allocated extra buffers in the end of a table for any new rows (inserts or updates). PG not knowing which rows are free for use is another problem, which causes table bloat, which deserves another post.
VACUUM FREEZE is special kind of VACUUM. From resource usage perspective, it differs from VACUUM by that it has to scan full table (normal VACUUM processes only buffers known to contain at