On Mon, 25 Feb 2008 22:29:32 -0800
Jeff Davis <pgsql@j-davis.com> 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
