Re: speed up restore from dump - Mailing list pgsql-general

From Sam Mason
Subject Re: speed up restore from dump
Date
Msg-id 20081031120708.GE2459@frubble.xen.chris-lamb.co.uk
Whole thread Raw
In response to Re: speed up restore from dump  (Alan Hodgson <ahodgson@simkin.ca>)
Responses Re: speed up restore from dump  (Robert Treat <xzilla@users.sourceforge.net>)
List pgsql-general
On Thu, Oct 30, 2008 at 02:28:38PM -0700, Alan Hodgson wrote:
> On Thursday 30 October 2008, Joao Ferreira <jmcferreira@critical-links.com>
> wrote:
> > well..... see for yourself... (360 RAM , 524 SWAP) that's what it is...
> > it supposed to be somewhat an embedded product...
>
> Clearly your hardware is your speed limitation. If you're swapping at all,
> anything running on the machine is going to be slow.

The vmstat output only showed the odd block going in and out; but
performance is only really going to suffer when it's thrashing.  If the
swap in number stays in the double digits for a reasonable amount of
time then you should probably look at what's causing it.  Giving memory
back to the system to use for caching the file system can be good, lots
of shared memory can also be good.

Building indexes takes time and IO bandwidth, maybe you could look at
building less of them?  I'd be tempted to pull the import script apart
into its constituent parts, i.e. the initial data load, and then all the
constraints/index builds separately.  Then run through executing them by
hand and see what you can change to make things more efficient.


   Sam

pgsql-general by date:

Previous
From: Sam Mason
Date:
Subject: Re: a LEFT JOIN problem
Next
From: Sam Mason
Date:
Subject: Re: Storage location of temporary files