Update on this issue, I "solved" my problem by doing the following: 1) Stopped the import, and did a checkpoint backup on my import target schema 2) Dropped the import target schema 3) Restored a backup from a previous checkpoint when the tables were much smaller 4) Performed a VACUUM/ANALYZE on all of the tables in the import target schema in that smaller state 5) Dropped the import target schema again 6) Restored the checkpoint backup of the larger data set referred to in step 1 7) Rstarted the import from where it left off The result: the import is flying again, with 10-20 times the performance. The import runs as 4 different TCL scripts in parallel, importing difernt segments of the table. The problem that I have when the import runs at this speed is that I hve to constantly watch for lock-ups. Previously I had reported that when these multiple processes are running at high speed, PostgreSQL occasionally freezes one or more of the processes by never retutning from a COMMIT. I look at the target tables, and it seems that the commit has gone through. This used to be a disaster because Ithought I had to restart every frozen proess by killing the script and restarting at the last imported row. Now I have found a way to un-freeze the program: I find the frozen process via PgAdmin III and send a CANCEL. To my surprise, the import continues as i nothing happened. Still incredibly inconvenient and laborious, but at least it's a little less tedious. Could these two problems - the weird slowdowns after a VACUUM/ANALYZE and the frequent lockups when the import process is running quickly - be related? Carlo
