parallel restore test results

I have just completed a test of the patch I posted a few days ago.

The test is a 2Gb dump file that restores to a 22Gb database. The 
database is very complex, with some 28,000 objects.

The baseline test was run in a single transaction:
   pg_restore --use-list tlist -1 -d mdata ../ned-int.pz

The parallel test was run with 8 concurrent threads, truncating the data 
members before load:
   pg_restore --use-list tlist -m 8 --truncate-before-load -d mdatap 
../ned-int.pz

The server is an 8-way machine running 2.66 Ghz Xeons running OpenSuse 
11.0. with Linux kernel 2.6.25. with 16gB of physical RAM.

Server settings:
   max_connections = 100                   # (change requires restart)   shared_buffers = 1GB                    # min
128kB  work_mem = 100MB                                # min 64kB   maintenance_work_mem = 200MB            # min 1MB
fsync= off                             # turns forced 
 
synchronization on or off   synchronous_commit = off                # immediate fsync at commit   full_page_writes =
off                 # recover from partial page 
 
writes   checkpoint_segments = 100               # in logfile segments, min 
1, 16MB each   autovacuum = off                        # Enable autovacuum 
subprocess?  'on'

Server version is CVS HEAD from yesterday some time.

Overall result: baseline: 4h32m  parallel: 0h 54m.

Breaking that down:
                     baseline         parallel   pre-data         35m                  16m   data load        38m
          20m*   post-data       3h29m                30m*
 

* these two steps overlap.


I am not sure why the pre-data load took so much longer in the baseline. 
I can only assume that there is a small penalty per object from doing it 
all in a single transaction. 

There was a single error on the parallel run, for which I am currently 
unable to account:

ERROR:  relation "foo" does not exist   Command was:
ALTER TABLE ONLY foo   ADD CONSTRAINT foo_role_fk FOREIGN KEY (foo_key, role_key) ....


But relation "foo" does indeed exist, and in fact three out of four of 
its FK constraints got created successfully.

cheers

andrew