Re: How to avoid transaction ID wrap

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.

In response to

Responses

Browse pgsql-hackers by date

  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