> > I think the vision is that the overflow table would never be very > > large because it can be vacuumed very aggressively. It has only tuples > > that are busy and will need vacuuming as soon as a transaction ends.
> > Unlike the main table which is mostly tuples that don't need > > vacuuming. Except when deleted :-) > Thats right. vacuum if it gets a chance to work on the > overflow relation seems to be doing a decent job in our runs. > If autovacuum/vacuum gets to run optimally, the FSM > information generated for the overflow relations will be able > to serve a lot of new tuple requests avoiding undue/large > bloat in the overflow relations. It seems like we would want to create a chain into overflow for deleted rows also (header + all cols null), so we can vacuum those too only by looking at overflow, at least optionally. I think the overflow would really need to solve deletes too, or the bitmap idea is more generally useful to vacuum. Generally for clear distinction I think we are talking about two things here. 1. reduce index bloat and maintenance work 2. allow vaccuum a cheaper focus on what needs to be done Andreas ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
