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.
