Re: pg_dump additional options for performance

Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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, by
creating the table (or truncating it) in the same transaction with the
COPY.

In the same transaction? Oh that's interesting. So that might be a TODO
right there. Change pg_dump so it does:

create,copy,create,copy,index

Instead 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +