Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 8EA429FB485 for ; Fri, 8 Jun 2007 11:30:02 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 43062-05 for ; Fri, 8 Jun 2007 11:29:43 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from crestone.coronasolutions.com (crestone.coronasolutions.com [66.45.104.24]) by postgresql.org (Postfix) with ESMTP id E34189FB739 for ; Fri, 8 Jun 2007 11:29:40 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by crestone.coronasolutions.com (Postfix) with ESMTP id 62449644730; Fri, 8 Jun 2007 08:29:26 -0600 (MDT) Received: from crestone.coronasolutions.com ([127.0.0.1]) by localhost (crestone.coronasolutions.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23820-07; Fri, 8 Jun 2007 08:29:24 -0600 (MDT) Received: from mac.local (c-76-25-77-161.hsd1.co.comcast.net [76.25.77.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by crestone.coronasolutions.com (Postfix) with ESMTP id 8A880644726 for ; Fri, 8 Jun 2007 08:29:24 -0600 (MDT) Message-ID: <466967C4.70606@drivefaster.net> Date: Fri, 08 Jun 2007 08:29:24 -0600 From: Dan Harris User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326) MIME-Version: 1.0 To: PostgreSQL Performance Subject: Re: [ADMIN] reclaiming disk space after major updates References: <46672F7C.4020400@drivefaster.net> <20070607192025.GO14087@phlogiston.dyndns.org> <46687820.9000604@drivefaster.net> <20070608140354.GV17144@phlogiston.dyndns.org> In-Reply-To: <20070608140354.GV17144@phlogiston.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at coronasolutions.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/152 X-Sequence-Number: 25185 Andrew Sullivan wrote: > On Thu, Jun 07, 2007 at 03:26:56PM -0600, Dan Harris wrote: >> They don't always have to be in a single transaction, that's a good idea to >> break it up and vacuum in between, I'll consider that. Thanks > > If you can do it this way, it helps _a lot_. I've had to do this > sort of thing, and breaking into groups of a couple thousand or so > really made the difference. > > A > One more point in my original post.. For my own education, why does VACUUM FULL prevent reads to a table when running (I'm sure there's a good reason)? I can certainly understand blocking writes, but if I could still read from it, I'd have no problems at all! -Dan