On Fri, Jun 09, 2006 at 06:20:21PM -0700, Trent Shipley wrote: > VACCUM needs to be run for two reasons. > 1) To recover the transaction counter. > 2) To recover records marked for deletion. > > VACCUM needs to be run over the entire database. If the data in the database > is N, then VACCUM is O(N). Roughly, VACCUM scales linearly with the size of > the database.
Well, you only need to vacuum the entire database once every billion transactions. Secondly, you can vacuum table by table. If you know a table will never be modified, you can VACUUM FREZZE it, then it will never need to be vacuumed again, ever (until you make changes ofcourse). > 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 why people suggest partitions. Then you only vacuum the partitions that are new and the old ones never need to be touched... Have a nice day, -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
signature.asc
Description: Digital signature
