Re: Autovacuum / full vacuum
От | Michael Riess |
---|---|
Тема | Re: Autovacuum / full vacuum |
Дата | |
Msg-id | dqj121$3jm$1@news.hub.org обсуждение исходный текст |
Ответ на | Re: Autovacuum / full vacuum (Andrew Sullivan <ajs@crankycanuck.ca>) |
Ответы |
Re: Autovacuum / full vacuum
|
Список | 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 по дате отправления: