Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore
От
Takahiro Itagaki
Тема
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore
Дата
Msg-id
20100210132455.47F4.52131E4D@oss.ntt.co.jp
Ответ на
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore (Andrew Dunstan)
Список
Дерево обсуждения
TRUNCATE+COPY optimization and --jobs=1 in pg_restore Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore Tom Lane <tgl@sss.pgh.pa.us>
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore Marc Cousin <cousinmarc@gmail.com>
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore Andrew Dunstan <andrew@dunslane.net>
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore Takahiro Itagaki <itagaki.takahiro@oss.ntt.co.jp>
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore Tom Lane <tgl@sss.pgh.pa.us>
Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore Robert Haas <robertmhaas@gmail.com>
Andrew Dunstan wrote: > Takahiro-san is suggesting there is a case for doing the optimisation in > non-parallel mode. But if we do that, is there still a case for > --single-transaction? I think --single-transaction is useful to restore data into non-empty databases. A normal restore ignores errors, but it might make database inconsistent state. So, we'd better keep --single-transaction option to support all-or-nothing restore. Regards, --- Takahiro Itagaki NTT Open Source Software Center
В списке pgsql-hackers по дате отправления
