On Mon, 25 Feb 2008 22:29:32 -0800 Jeff Davis <[EMAIL PROTECTED]> wrote:
> For me it would still be very helpful. If that 100GB table has several > indexes, particularly on localized text, that can take a lot of > processor time to rebuild (even for a substantially smaller dataset, > like in the "7 hour restore" thread). It seems like a no-brainer to be > able to utilize all available cores. Oh, I agree that we should be using all cores. I would argue that we should have been doing that for years now but more importantly to me is that pg_restore even single threaded is slow. > > I think we should consider all of these pg_restore improvements, > because they're merely simplifying the DBA's job. Currently, to get > these benefits, I have to organize and parallelize the restore > manually. Definitely. > > Actually, the tests you're running are helping me as much as any > pg_restore changes might anyway. I don't mind a small amount of extra > work to dump/restore, but other users might get a bad impression of > PostgreSQL if they don't know how to make it perform to their > expectations. Certainly but having to hand roll this is bad. It presents us in a decidedly hackish light. Sincerely, Joshua D. Drake > > Regards, > Jeff Davis > -- 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
