From: | Michael Riess <mlriess(at)gmx(dot)de> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Autovacuum / full vacuum |
Date: | 2006-01-17 15:04:41 |
Message-ID: | dqj121$3jm$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Stone | 2006-01-17 15:07:32 | Re: Autovacuum / full vacuum |
Previous Message | Andrew Sullivan | 2006-01-17 14:56:49 | Re: Autovacuum / full vacuum |