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.
