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