On 8/9/07, Simon Riggs <simon@2ndquadrant.com> 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
