Re: pg_dump additional options for performance

Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Added to TODO based on this discussion:
> 
> >         o To better utilize resources, restore data, primary keys, and
> >           indexes for a single table before restoring the next table
> 
> That idea seems quite misguided, and certainly was not anywhere in the
> prior discussion.  If you add an ordering constraint as strong as that,
> you'll mostly just eliminate chances for parallelism.

The idea comes from this email, which no one objected to:
http://search.postgresql.org/search?m=1&q=pg_dump+create+copy&l=&d=&s=
    You could avoid the ~8% spent in XLogInsert in PostgreSQL 8.3, bycreating the table (or truncating it) in the same
transactionwith theCOPY. In the same transaction? Oh that's interesting. So that might be a TODOright there. Change
pg_dumpso it does:create,copy,create,copy,indexInstead of:create,create,copy,copy,index
 


> Also, the
> following para describes something completely different:
> 
> >           Hopefully this will allow the CPU-I/O load to be more uniform
> >           for simultaneous restores.  The idea is to start data restores
> >           for several objects, and once the first object is done, to move
> >           on to its primary keys and indexes.  Over time, simultaneous
> >           data loads and index builds will be running.

OK, let me remove the entire item and we can always re-add it if someone
want to make a case for it.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://postgres.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +