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. +