"Tom Lane" <[EMAIL PROTECTED]> writes:

> "Pavan Deolasee" <[EMAIL PROTECTED]> writes:
>> 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.
> Doesn't this design completely fail to take index bloat into account?
> Repairing heap fragmentation does not reduce the need for VACUUM to work
> on the indexes.

Index bloat is a bit of an open issue already. Because page splits already
prune any LP_DELETEd pointers any busy index keys will be pruned already.

However any index keys which have not been the subject of an index lookup --
and that includes keys which are only accessed by bitmap-index-scans -- won't
be pruned.

So we don't really know how much bloat is currently in an index. Perhaps we
need a new statistic which gets updated whenever a page split prunes
LP_DELETEd pointers (or perhaps when LP_DELETE is set?).

  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at


Reply via email to