Re: pg_dump additional options for performance

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump additional options for performance
Date: 2008-03-04 01:56:27
Message-ID: 4106.1204595787@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message jomarba 2008-03-04 02:01:50 pt_br translation
Previous Message Bruce Momjian 2008-03-04 01:40:02 Re: 8.3 / 8.2.6 restore comparison