Ways to speed up dump&reload

From: "Markus Wollny" <Markus(dot)Wollny(at)computec(dot)de>
To: <pgsql-general(at)postgresql(dot)org>
Subject: Ways to speed up dump&reload
Date: 2005-02-21 06:11:48
Message-ID: 2266D0630E43BB4290742247C891057502B9D6C4@dozer.computec.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hello!

Finally the time has come for us to upgrade our PostgreSQL 7.4.5-servers to 8.0.1 - and though I'm very much looking forward to some of the new features, the dump&reload process is worrying me a bit this time. I've got one cluster in particular which is roughly 9GB in size and features some dreadfully large indices of the GiST-type for Tsearch2.

I have already scheduled a nightshift for this upgrade, but I'm not all too certain that I'll be up and running again in the morning, so I wondered if there might be some preparations that would allow for some speed-up during the reload process? What kind of tuning could be done in postgresql.conf in respect to just this particular workload (COPY and finally the CREATE INDEX stuff) with no other concurrent access going on?

The machine in question features a RAID10 disk array which hosts the DB-cluster, some 2GB RAM and four processors and I've tuned postgresql.conf for our ordinary everyday workload with lots and lots of concurrent reads and writes, but I've got the feeling that this configuration might not be the optimum for dump&reload, so it might make some sense to use some sort of "maintenance"-configuration. What kind of tuning would you recommend?

Thank you very much for your advice and lots of cheers to the developers for 8.0!

Kind regards

Markus

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Surabhi Ahuja 2005-02-21 07:17:58 error while loading shared libraries: libpq.so.3
Previous Message phil campaigne 2005-02-21 00:02:44 Re: Problem with select statement