Re: Recovering real disk space

Поиск
Список
Период
Сортировка
От Thomas F.O'Connell
Тема Re: Recovering real disk space
Дата
Msg-id 4b1ef1a12e19a76e36f59d3a3f7a41d7@sitening.com
обсуждение исходный текст
Ответ на Re: Recovering real disk space  (Bruno Wolff III <bruno@wolff.to>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: invalid input syntax for type bytea
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] plPHP in core?