From: | Steve Peterson <stevep-hv(at)zpfe(dot)com> |
---|---|
To: | <me(at)alternize(dot)com>,<pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: UPDATE becomes mired / win32 |
Date: | 2006-10-05 05:06:49 |
Message-ID: | 6.2.3.4.0.20061005000508.04bb03d8@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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(at)alternize(dot)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
>
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2006-10-05 06:26:23 | Re: Performance Optimization for Dummies 2 - the SQL |
Previous Message | Steve Peterson | 2006-10-05 04:56:11 | Re: UPDATE becomes mired / win32 |