Re: Dead Space Map for vacuum

On Fri, 2006-12-29 at 10:49 -0500, Tom Lane wrote:
> "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > I would suggest that we tracked whether a block has had 0, 1 or 1+
> > updates/deletes against it. When a block has 1+ it can then be
> > worthwhile to VACUUM it and to place it onto the FSM. Two dead tuples is
> > really the minimum space worth reclaiming on any block.
>
> How do you arrive at that conclusion?

FSM code ignores any block with less space than 1 average tuple, which
is a pretty reasonable rule.

If you only track whether a block has been updated, not whether it has
been updated twice, then you will be VACUUMing lots of blocks that have
only a 50% chance of being usefully stored by the FSM. As I explained,
the extra bit per block is easily regained from storing less FSM data.

My understanding was that DSM was meant to increase VACUUM efficiency,
so having a way to focus in on blocks most worth vacuuming makes sense
using the 80/20 rule.

> Counterexample: table in which all tuples exceed half a page.

Current FSM code will ignore those too, if they are less than the
average size of the tuple so far requested. Thats a pretty wierd
counterexample, even if it is a case that needs handling.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com