On Wed, Feb 10, 2010 at 12:19 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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...
Is this a fatal defect or is there a way to salvage this idea? Another possible issue is that this changes the behavior. Suppose the table wasn't empty before we truncated it... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
