Re: reclaiming diskspace bloat w/near-zero downtime - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: reclaiming diskspace bloat w/near-zero downtime
Date
Msg-id 20041203085451.GA25113@svana.org
Whole thread Raw
In response to reclaiming diskspace bloat w/near-zero downtime  ("Ed L." <pgsql@bluepolka.net>)
Responses Re: reclaiming diskspace bloat w/near-zero downtime  ("Ed L." <pgsql@bluepolka.net>)
List 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@svana.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.

Attachment

pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: pgFoundary?
Next
From: Chris Green
Date:
Subject: Re: Is there a way to view a rewritten query?