On Tuesday 19 February 2008 13:13:37 Richard Huxton wrote: > Douglas J Hunley wrote: > > I spent a whopping seven hours restoring a database late Fri nite for a > > client. We stopped the application, ran pg_dump -v -Ft -b -o $db > > > ~/pre_8.3.tar on the 8.2.x db, and then upgrading the software to 8.3. I > > then did a pg_restore -v -d $db ./pre_8.3.tar and watched it positively > > crawl. I'll grant you that it's a 5.1G tar file, but 7 hours seems > > excessive. > > Depends, both on the machine and the database. > > What sort of disk i/o are you seeing, what's the cpu(s) doing, and > what's the restore taking so long over (since you have -v)? The I/O didn't seem abnormal to me for this customer, so I didn't record it. It wasn't excessive though. It took the longest on a couple of our highest volume tables. By far index creation took the longest of the entire process > > Oh, and have you tweaked the configuration settings for the restore? > Lots of work_mem, turn fsync off, that sort of thing. I didn't tweak anything for the restore specifically. Used the postgresql.conf as attached in another reply -- Douglas J Hunley (doug at hunley.homeip.net) - Linux User #174778 http://doug.hunley.homeip.net One item could not be deleted because it was missing. -- Mac System 7.0b1 error message ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
