Re: Recovering real disk space - Mailing list pgsql-general

From Thomas F.O'Connell
Subject Re: Recovering real disk space
Date
Msg-id 4b1ef1a12e19a76e36f59d3a3f7a41d7@sitening.com
Whole thread Raw
In response to Re: Recovering real disk space  (Bruno Wolff III <bruno@wolff.to>)
List 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@sycamore.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.

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: invalid input syntax for type bytea
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] plPHP in core?