X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 11B119DC94A for ; Tue, 17 Jan 2006 11:04:43 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 52541-06 for ; Tue, 17 Jan 2006 11:04:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by postgresql.org (Postfix) with ESMTP id 00C3A9DC959 for ; Tue, 17 Jan 2006 11:04:39 -0400 (AST) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id 7784E30F0A; Tue, 17 Jan 2006 16:04:44 +0100 (MET) From: Michael Riess X-Newsgroups: pgsql.performance Subject: Re: Autovacuum / full vacuum Date: Tue, 17 Jan 2006 16:04:41 +0100 Organization: Hub.Org Networking Services Lines: 31 Message-ID: References: <20060117145649.GE21092@phlogiston.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: Thunderbird 1.5 (Windows/20051201) In-Reply-To: <20060117145649.GE21092@phlogiston.dyndns.org> To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.068 required=5 tests=[AWL=0.068] X-Spam-Score: 0.068 X-Spam-Level: X-Archive-Number: 200601/237 X-Sequence-Number: 16715 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.