On 8/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > > > Whether I got the exact details of frugging & depruning correct or not: > if a tuple version is removed, then VACUUM doesn't need to remove it > later, so any non-VACUUM removal of rows must defer a VACUUM. > >
ISTM that you are worried about the cases where a tuple is HOT updated and hence can be pruned/defragged, but only if we revisit the page at a later time. What if we just track the amount of potentially dead space in the relation (somebody had suggested that earlier in the thread) ? Every committed UPDATE/DELETE and aborted UPDATE/INSERT would increment the dead space. Whenever page fragmentation is repaired, either during normal operation or during vacuum, the dead space is reduced by the amount of reclaimed space. Autovacuum triggers whenever the percentage of dead space increases beyond a threshold. We can some fine tuning to track the space consumed by redirect-dead line pointers. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
