Hello, I have been testing a migration for a week now trying to get it into a reasonable state. This is what we have:
Restore file 220G 8.2.6 and 8.3.0 are configured identically: shared_buffers = 8000MB work_mem = 32MB maintenance_work_mem = 512MB fsync = off full_page_writes = off checkpoint_segments = 300 synchronous_commit = off (8.3) wal_writer_delay = off (8.3) autovacuum = off 8.2.6 after 2 hours has restored 41GB. 8.3.0 after 2.5 hours had restored 38GB. Originally I was thinking that 8.2.6 was stomping 8.3. However I am thinking that the reduction in the tuple header sizes for 8.3 means that yes I restored 38GB, it is actually *more* data than 8.2.6. Does that seem accurate to everyone else? If so what can we do to speed this up? We are certainly *not* saturating the disk (16 spindles SCSI). I am thinking the way we are going to need to do this is to have an extended outage and write a custom script to do a concurrent dump and load. (no in this case slony is not an option). Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL SPI Liaison | SPI Director | PostgreSQL political pundit
signature.asc
Description: PGP signature