Re: How to avoid transaction ID wrap

Jim C. Nasby wrote:
> On Fri, Jun 09, 2006 at 06:20:21PM -0700, Trent Shipley wrote:
> > Ideally, the transaction management system would be proportional to the 
> > marginal change in size of the database rather than the gross size of the 
> > database.  That is VACCUM being O(N) should be replaced (or there should be 
> > an optional alternative) that scales with D, O^k(D) where any k > 1 involves 
> > a tradeoff with VACCUM.  
> 
> That's something that's been discussed quite a bit; search the archives
> for 'dead space map'. Granted, that wasn't targeted so much at the need
> to VACUUM FREEZE, but there's no reason it wouldn't be possible to make
> it handle that as well. In the mean time, if you partition the table on
> date, you won't need to be vacuuming the entire database to handle XID
> wrap.

FWIW my patch for vacuum fixes some of these issues.  First because you
can freeze a table and will never need to vacuum it again; database-wide
vacuums will not be necessary.  And secondly, because as soon as a table
is frozen (either because you VACUUM FREEZE'd it, or because regular
vacuuming froze all tuples on it completely), then you don't need to
vacuum it again and indeed (non-full) VACUUM turns into a no-op.

Mix this with partitioned tables.