Message-Id: <6.2.3.4.0.20061005000508.04bb03d8@localhost>
Date: Thu, 05 Oct 2006 00:06:49 -0500
To: <me@alternize.com>,<pgsql-performance@postgresql.org>
From: Steve Peterson <stevep-hv@zpfe.com>
Subject: Re: UPDATE becomes mired / win32
In-Reply-To: <0d3301c6e7e0$ce71c190$6501a8c0@iwing>
References: <6.2.3.4.0.20061004094635.03c114a8@localhost>
	<0d3301c6e7e0$ce71c190$6501a8c0@iwing>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format=flowed

I'm pretty sure that the table was empty before doing the load, but I 
gave this a shot.  It didn't have an impact on the results.

The behavior also persists across a dump/reload of the table into a 
new install on a different machine.  IIRC dump/reload rebuilds 
indexes from scratch.

Steve

At 01:13 PM 10/4/2006, me@alternize.com wrote:
>>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
>