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

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

Reply via email to