Re: pg_dump additional options for performance - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump additional options for performance
Date
Msg-id 4106.1204595787@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump additional options for performance  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_dump additional options for performance  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
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.  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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 8.3 / 8.2.6 restore comparison
Next
From: Bruce Momjian
Date:
Subject: Re: pg_dump additional options for performance