> > I think the vision is that the overflow table would never be very 
> > large because it can be vacuumed very aggressively. It has only
> > 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
at overflow, at least optionally.

I think the overflow would really need to solve deletes too, or the
idea is more generally useful to vacuum.

Generally for clear distinction I think we are talking about two things
1. reduce index bloat and maintenance work
2. allow vaccuum a cheaper focus on what needs to be done 


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to