Re: reclaiming diskspace bloat w/near-zero downtime

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: "Ed L(dot)" <pgsql(at)bluepolka(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: reclaiming diskspace bloat w/near-zero downtime
Date: 2004-12-03 08:54:51
Message-ID: 20041203085451.GA25113@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I can't help you with your general enquiry, but some comments:

On Thu, Dec 02, 2004 at 11:06:08PM -0700, Ed L. wrote:
> If I UPDATE 10000 rows and then run vacuum, I was expecting/hoping that a
> subsequent UPDATE of 9000 rows would largely reuse the space reclaimed from
> the 10000-row UPDATE.]

For this, check the FSM settings. It can only keep track of a limited
number of pages. So if your tuples are large it may not be able to
track it all...

The FSM should be set big enough to cover all the space that might be
updated/deleted between two VACUUMs. So it might make to set the FSM to
be quite large and vacuum (not FULL) often. These should bring the
growth to a halt if the table really is quite empty.

As for the foreign key issue, the basic problem is that the functions
reference the OIDs of the tables. So it wil track the tables, even
through renames. I don't have an answer for you here...

Hope this helps,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Chris Green 2004-12-03 09:03:57 Re: Is there a way to view a rewritten query?
Previous Message ON.KG 2004-12-03 07:14:50 Re: Select Database