On Tue, 2007-08-14 at 13:24 +0530, Pavan Deolasee wrote:
>
>
> On 8/9/07, Simon Riggs <simon@2ndquadrant.com> 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
