Re: Autovacuum / full vacuum - Mailing list pgsql-performance

From Michael Riess
Subject Re: Autovacuum / full vacuum
Date
Msg-id dqj121$3jm$1@news.hub.org
Whole thread Raw
In response to Re: Autovacuum / full vacuum  (Andrew Sullivan <ajs@crankycanuck.ca>)
Responses Re: Autovacuum / full vacuum
List pgsql-performance
Hi,

>> hi,
>>
>> I'm curious as to why autovacuum is not designed to do full vacuum. I
>
> Because nothing that runs automatically should ever take an exclusive
> lock on the entire database, which is what VACUUM FULL does.

I thought that vacuum full only locks the table which it currently
operates on? I'm pretty sure that once a table has been vacuumed, it can
be accessed without any restrictions while the vacuum process works on
the next table.

>
>> activity. Increasing the FSM so that even during these bursts most space
>>  would be reused would mean to reduce the available memory for all
>> other database tasks.
>
> I don't believe the hit is enough that you should even notice it.
> You'd have to post some pretty incredible use cases to show that the
> tiny loss of memory to FSM is worth (a) an exclusive lock and (b) the
> loss of efficiency you get from having some preallocated pages in
> tables.

I have 5000 tables and a workstation with 1 GB RAM which hosts an Apache
   Web Server, Tomcat Servlet Container and PostgreSQL. RAM is not
something that I have plenty of ... and the hardware is fixed and cannot
be changed.



pgsql-performance by date:

Previous
From: Andrew Sullivan
Date:
Subject: Re: Autovacuum / full vacuum
Next
From: Michael Stone
Date:
Subject: Re: Autovacuum / full vacuum