Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id C0C681337B9D for ; Fri, 28 Jan 2011 13:10:06 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 44955-05 for ; Fri, 28 Jan 2011 17:09:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mxnip01-missouri-out.um.umsystem.edu (mxnip01-missouri-out.um.umsystem.edu [209.106.229.53]) by mail.postgresql.org (Postfix) with ESMTP id 6A28B1337B96 for ; Fri, 28 Jan 2011 13:09:59 -0400 (AST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHOHQk3RauQW/2dsb2JhbAClAHOyX4hphU8EhRiKUwY Received: from um-tsmtpin1.um.umsystem.edu ([209.106.228.22]) by mxnip01-mizzou-out.um.umsystem.edu with ESMTP; 28 Jan 2011 11:09:58 -0600 Received: from um-tsmtpout1.um.umsystem.edu ([209.106.228.23]) by um-tsmtpin1.um.umsystem.edu with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jan 2011 11:09:54 -0600 Received: from [128.206.129.163] ([128.206.129.163]) by um-tsmtpout1.um.umsystem.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 28 Jan 2011 11:09:54 -0600 Message-ID: <4D42F861.9000000@missouri.edu> Date: Fri, 28 Jan 2011 11:09:53 -0600 From: Robert Schnabel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Scott Marlowe CC: Stephen Frost , "david@lang.hm" , pgsql-performance Subject: Re: How to best use 32 15k.7 300GB drives? References: <4D41F92F.9030006@missouri.edu> <4D420D61.3000109@missouri.edu> <20110128131410.GC30352@tamriel.snowman.net> <4D42F127.9050307@missouri.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jan 2011 17:09:54.0318 (UTC) FILETIME=[2EA4A2E0:01CBBF0E] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201101/317 X-Sequence-Number: 42104 On 1/28/2011 11:00 AM, Scott Marlowe wrote: > On Fri, Jan 28, 2011 at 9:39 AM, Robert Schnabel wrote: >> I can't do outside the database. So yes, once the upload is done I run >> queries that update every row for certain columns, not every column. After >> I'm done with a table I run a VACUUM ANALYZE. I'm really not worried about >> what my table looks like on disk. I actually take other steps also to avoid >> what you're talking about. > It will still get bloated. If you update one column in one row in pg, > you now have two copies of that row in the database. If you date 1 > column in 1M rows, you now have 2M rows in the database (1M "dead" > rows, 1M "live" rows). vacuum analyze will not get rid of them, but > will free them up to be used in future updates / inserts. Vacuum full > or cluster will free up the space, but will lock the table while it > does so. > > There's nothing wrong with whole table updates as part of an import > process, you just have to know to "clean up" after you're done, and > regular vacuum can't fix this issue, only vacuum full or reindex or > cluster. Those are exactly what I was referring to with my "other steps". I just don't always do them as soon as I'm done updating because sometimes I want to query the table right away to find out something. Yep, I found out the hard way that regular VACUUM didn't help.