Re: HOT patch, missing things - Mailing list pgsql-hackers

From Decibel!
Subject Re: HOT patch, missing things
Date
Msg-id 20070808170047.GG20424@nasby.net
Whole thread Raw
In response to Re: HOT patch, missing things  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
List pgsql-hackers
On Wed, Aug 08, 2007 at 04:45:44PM +0530, Pavan Deolasee wrote:
> On 8/8/07, Gregory Stark <stark@enterprisedb.com> wrote:
> > It seems that previously percentage of tuples made sense because dead
> > tuples
> > took about the same amount of space as new tuples that need that space.
> > But
> > line pointers take much less space than the new tuples so the number of
> > dead
> > line pointers we need before we can recover a useful amount of space
> > depends
> > on the ratio of line pointer size to tuple size.
> >
> > Perhaps we should be gathering "bytes of dead tuples" in pg_stat not just
> > n_dead_tuples.
>
> This is a good idea. Alternatively, we can guess percentage of dead space
> using the average tuple size, number of dead tuples and number of reltuples.
>
> Another thing to worry about is index bloats. Even though a redirect-dead
> line pointer takes only 4 bytes in the heap, the associated dead space
> in the index is as large as any other index tuple and the index
> might be in a need for vacuum.

...and bloat in indexes is generally going to be a lot more critical
than table bloat. Heck, there's probably a lot of cases where you could
go a very long time without vacuuming the heap, if only you could keep
indexes under control.

Whichever way we go, we should keep the vacuum parameter associated with
actual bloat, which makes it much easier to set. If we wanted to get
fancy, perhaps we could track the amount of bloat in the heap as well as
the indexes, and trigger a vacuum when either one exceeded a threshold.
--
Decibel!, aka Jim Nasby                        decibel@decibel.org
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)

pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: pg_lzcompress strategy parameters
Next
From: Michael Glaesemann
Date:
Subject: Re: [mmoncure@gmail.com: Re: [GENERAL] array_to_set functions]