| From: | Scott Marlowe <smarlowe(at)g2switchworks(dot)com> |
|---|---|
| To: | "mcelroy, tim" <tim(dot)mcelroy(at)bostonstock(dot)com> |
| Cc: | 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ruairi <rcarroll(at)bluemetrix(dot)com>, pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Restore of pg_dump taking a long time... |
| Date: | 2006-05-24 19:00:10 |
| Message-ID: | 1148497210.25526.22.camel@state.g2switchworks.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Wed, 2006-05-24 at 13:56, mcelroy, tim wrote:
> I have found that the following steps have increased the speed of my
> restores:
> 1. dropdb <DBNAME>
> 2. createdb <DBANME>
> 3. Increase maintenance_work_mem as Tom mentioned. I do this at
> restore/runtime
> 4. Increase work_mem as Tom mentioned. I do this at restore/runtime
> 5. renice -20 -p <pid #> (on a Linux box) <= This step can be
> performed while the restore is running but you need root privilege
Note that if there's no other data in the database that you need to
worry about, you can also restore with fsync off. I.e. if a database
cluster could just be re-inited should a power failure occur.
If you've got already important data you can't afford to lose in the
cluster, then do not turn off fsync.
Also, remember to turn it back on before you go into production.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Todd A. Cook | 2006-05-24 19:42:25 | Re: Restore of pg_dump taking a long time... |
| Previous Message | mcelroy, tim | 2006-05-24 18:56:30 | Re: Restore of pg_dump taking a long time... |