Re: 8.3 / 8.2.6 restore comparison

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