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. BTW, you're also ignoring the fact that technology keeps improving the hardware that's out there. It's possible that hardware advances alone would keep pace with your vacuuming needs. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org