Andrew Dunstan <and...@dunslane.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers