Re: 8.3 / 8.2.6 restore comparison

On Mon, 2008-02-25 at 21:18 -0800, Joshua D. Drake wrote:
> As simple as this solution is, it is not eloquent nor is it smart.
> Using this method, if you have a 100GB table (which is very common)
> you are still bound in a bad way by a single connection and you are
> holding up everyone else.

In your case I can see your point.

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.

I think one big improvement is to break it into steps as Simon suggests
here:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php

and my idea to further break it down:
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00699.php

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.

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.

Regards,
Jeff Davis