From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Trent Shipley <tshipley(at)deru(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to avoid transaction ID wrap |
Date: | 2006-06-10 16:11:02 |
Message-ID: | 20060610161102.GA10174@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-06-10 16:23:06 | Re: ADD/DROP INHERITS |
Previous Message | Ian Caulfield | 2006-06-10 15:54:23 | Re: Ranges for well-ordered types |