Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 2D2549FB20C for ; Wed, 4 Oct 2006 15:14:02 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 20988-02-2 for ; Wed, 4 Oct 2006 15:13:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.refusion.com (mail.refusion.com [213.144.155.20]) by postgresql.org (Postfix) with ESMTP id 8CCF49FB24B for ; Wed, 4 Oct 2006 15:13:50 -0300 (ADT) Received: from iwing by mail.refusion.com (Cipher TLSv1:RC4-MD5:128) (MDaemon PRO v9.0.7) with ESMTP id md50001315391.msg for ; Wed, 04 Oct 2006 20:13:44 +0200 Message-ID: <0d3301c6e7e0$ce71c190$6501a8c0@iwing> From: To: , "Steve Peterson" References: <6.2.3.4.0.20061004094635.03c114a8@localhost> Subject: Re: UPDATE becomes mired / win32 Date: Wed, 4 Oct 2006 20:13:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.2663 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757 X-Authenticated-Sender: info@alternize.com X-Spam-Processed: mail.refusion.com, Wed, 04 Oct 2006 20:13:44 +0200 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 80.238.207.183 X-Return-Path: me@alternize.com X-Envelope-From: me@alternize.com X-MDaemon-Deliver-To: pgsql-performance@postgresql.org X-ClamAV: Pass X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.091 tagged_above=0 required=5 tests=AWL, NO_REAL_NAME, SPF_HELO_PASS, UNPARSEABLE_RELAY X-Spam-Level: * X-Archive-Number: 200610/108 X-Sequence-Number: 21237 > The table, VOTER, contains 3,090,013 rows and each row is about 120 bytes > wide. It's loaded via a batch process in one shot, and the load is > followed by an VACUUM FULL ANALYZE. Its structure is shown at the bottom > of the message. if the table wasn't empty before and has indices defined, try a "REINDEX TABLE VOTER" before running the update. i had a similar case where an often updated table was vacuumed regurarly, but the indices grew and grew and grew. in my case the table - even when empty and analyze full'ed was 1.2gb according to pgadmin due to (outdated) indices. a reindex fixed all my performance issues. - thomas