Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 8157C9FA492 for ; Sun, 26 Nov 2006 12:28:50 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 67454-06 for ; Sun, 26 Nov 2006 12:28:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from 66-226-76-106.dedicated.abac.net (66-226-76-106.dedicated.abac.net [66.226.76.106]) by postgresql.org (Postfix) with ESMTP id 59BA59FA48A for ; Sun, 26 Nov 2006 12:28:46 -0400 (AST) Received: (qmail 30131 invoked by uid 2020); 26 Nov 2006 09:30:47 -0800 Received: from wsip-70-167-125-69.sd.sd.cox.net (HELO ?192.168.0.3?) (70.167.125.69) by 66-226-76-106.dedicated.abac.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Nov 2006 09:30:47 -0800 Message-ID: <4569C04C.8090503@modgraph-usa.com> Date: Sun, 26 Nov 2006 08:26:52 -0800 From: "Craig A. James" User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: When to vacuum a table? References: <1164540257.7902.0.camel@panoramix> <20061126131147.GA4089@uio.no> <195C9B6B-2018-474C-AA80-239A8CEA37E9@gmail.com> In-Reply-To: <195C9B6B-2018-474C-AA80-239A8CEA37E9@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.898 tagged_above=0 required=5 tests=AWL, BAYES_40, HELO_DYNAMIC_IPADDR2 X-Spam-Level: ** X-Archive-Number: 200611/223 X-Sequence-Number: 21993 Rod Taylor wrote: >> Just a minor clarification here: INSERT does not create dead rows, only >> UPDATE and DELETE do. Thus, if you only insert rows, you do not need to >> vacuum (although you probably need to analyze). Is there no real-time garbage collection at all in Postgres? And if so, is this because nobody has had time to implement garbage collection, or for a more fundamental reason, or because VACUUM is seen as sufficient? I'm just curious ... Vacuum has always seemed to me like an ugly wart on the pretty face of Postgres. (I say this even though I implemented an identical solution on a non-relational chemistry database system a long time ago. I didn't like it then, either.) Craig