"beer@xxxxxxx" <beer@xxxxxxx> writes: > The problem with pg_restore is that our database takes 3+ weeks to restore > from a dump file. This is not an acceptable window for us. ( Approximately > 3 days of this is data + lobs, and the rest indexes and constraints. If we > are doing something wrong here, I am all ears as well ) Uh, how big is that database exactly? One question is, if migration is so painful, why are you updating to a branch that is already obsolete? At this point you should be skipping 8.1.x and going directly to 8.2.x; or maybe planning to wait a few more weeks and go to 8.3.x. I say this not just on general principles, but mindful of the fact that there were some pretty significant improvements in sorting speed in 8.2, which would translate directly to shorter btree index build times. (Are all your indexes btrees?) Also, are you following the guidelines at http://developer.postgresql.org/pgdocs/postgres/populate.html#POPULATE-PG-DUMP ? regards, tom lane ---------------------------(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
