From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Takahiro Itagaki <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore |
Date: | 2010-02-10 04:19:04 |
Message-ID: | 7876.1265775544@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> The code is only trying to substitute for something you can't have
>> in parallel restore, ie --single-transaction.
> Exactly. IIRC that's why --single-transaction was introduced in the
> first place.
To me, --single-transaction is mostly there for people who want to be
sure they have all-or-nothing restore behavior. Optimizations are
secondary.
> 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?
Yeah, per above. The main problem I have with doing it in non-parallel
restore mode is that we couldn't safely do it when outputting to a
script (since we don't know if the user will try to put begin/end
around the script), and I really do not want to allow any differences
between script output and direct-to-database output. Once that camel's
nose gets under the tent, debuggability will go down the tubes...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Takahiro Itagaki | 2010-02-10 04:24:55 | Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore |
Previous Message | Andrew Dunstan | 2010-02-10 04:13:52 | Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore |