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@xxxxxxxxxxxxx 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
