And you are here why?

“Vacuum Stories” are pretty much a rite of passage for Postgres Peoples. Mind you, we don’t automatically flinch anymore when you whisper ”VACUUM” into our ears, but it’s still not an automagic thing — You really need to know what’s going on under the hood if you’re doing anything beyond the basics (•) The underlying issue in Postgres is that when a row needs to be updated, 1. A new version is created that is visible only to the transaction that created it 2. Once the transaction commits, the new row is visible to all subsequent transactions 3. Existing transactions will continue to see the old row 4. When there are no more “existing” transactions, the old row is deleted The ensuing space-management issues are the proximate cause for most of the vacuum stories out there, and  is based on the way Postgres implements MVCC . PostgreSQL’s approach to this problem is to store new row versions created by UPDATE in basically the same way that it would store a completely ...