Re: 8.3 / 8.2.6 restore comparison
От | Jeff Davis |
---|---|
Тема | Re: 8.3 / 8.2.6 restore comparison |
Дата | |
Msg-id | 1204007372.10798.47.camel@jdavis обсуждение исходный текст |
Ответ на | Re: 8.3 / 8.2.6 restore comparison ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: 8.3 / 8.2.6 restore comparison
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: