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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
