On Thu, 2006-12-28 at 21:35 +0000, Heikki Linnakangas wrote:
> I only used 1 bit, just like in Itagaki's approach.
1 bit may not be enough.
In many cases, a block will receive only 1 UPDATE or DELETE. If we then
mark this in the DSM, when we VACUUM that block it will not have
sufficient space free to make it worth VACUUM adding the block to the
FSM (using current thinking). That thinking is good, since tuples
frequently vary in length, so we could easy be in a position that a
block in the FSM doesn't even have space for a single new tuple version.
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.
Otherwise we will end up with a huge, not very useful FSM and fairly
inefficient VACUUMing of single dead tuples.
So I'd suggest that we used at least 2 bits/block, so that we can avoid
fiddling with small amounts of reclaimed space. The extra space taken up
by the DSM is easily outweighed by the space we would have wasted in the
FSM to make it effective when tracking smaller chunks of freespace
(which needs 6 bytes/block).
DSM is a good thing; many use cases will benefit from it.
I'd want to be able to turn off DSM completely when the whole database
fits in RAM and would probably like to enable/disable it for particular
tables, until we get some good heuristics for when it is worthwhile.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com