From: | Thomas F(dot)O'Connell <tfo(at)sitening(dot)com> |
---|---|
To: | Bruno Wolff III <bruno(at)wolff(dot)to> |
Cc: | pgsql-general(at)postgresql(dot)org, Adam Siegel <adam(at)sycamore(dot)us> |
Subject: | Re: Recovering real disk space |
Date: | 2005-04-04 16:00:28 |
Message-ID: | 4b1ef1a12e19a76e36f59d3a3f7a41d7@sitening.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Isn't this also a symptom of inappropriate FSM settings?
Try running a VACUUM VERBOSE and check the FSM settings at the end.
-tfo
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source — Open Your i™
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005
On Apr 3, 2005, at 8:21 AM, Bruno Wolff III wrote:
> On Wed, Mar 30, 2005 at 13:09:33 -0500,
> Adam Siegel <adam(at)sycamore(dot)us> wrote:
>>
>> We perform a vacuum full after each mass delete. This cycle can
>> happen
>> many times during over a couple of weeks. We are in a test lab
>> environment and are generating a lot of data.
>>
>> One of the problems we have is that the vacuum on the table can take
>> up
>> to 10 hours. We also expect to see the physical disk space go down,
>> but
>> this does not happen. If we accidently fill up the disk, then all
>> bets
>> are off and we are unable to recover. A vacuum never seems to finish
>> (several days).
>
> This may mean that there are open transactions pinning the records you
> have deleted so that they aren't being removed by the vacuum.
> Also, under some circumstances a CLUSTER can be faster than a VACUUM
> FULL.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-04-04 16:01:41 | Re: [HACKERS] plPHP in core? |
Previous Message | Wes | 2005-04-04 15:38:56 | Re: Vacuum time degrading |