On Tue, 2007-08-14 at 13:24 +0530, Pavan Deolasee wrote: > > > On 8/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > On Thu, 2007-08-09 at 15:46 +0530, Pavan Deolasee wrote: > > > > > 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. > > Sounds great. > > > > So do we have consensus here ? Fortunately, I think there won't be any > changes to user interface. Users can still use the vacuum_scale_factor > to > tune autovacuum, but instead of percentage of dead tuples, it would > signify percentage of dead space in the relation.
We have some consensus, but no complete design. My understanding is that we would see the following things tracked in pg_stats_xxx n_tup_ins count of rows inserted n_tup_upd count of rows updated (incl HOT and cold) n_tup_del count of rows deleted - the above are required because they are already there and useful too n_tup_hot_upd count of rows updated by HOT method only - the above is required to help tune HOT/cold updates dead_space total number of dead bytes in table - the above is required for autovacuum -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
