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. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend