From: | Palle Girgensohn <girgen(at)pingpong(dot)net> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: reduce downtime when upgrading 7.3 -> 7.4 |
Date: | 2004-02-10 16:24:08 |
Message-ID: | 51450000.1076430248@rambutan.pingpong.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
--On Tuesday, February 10, 2004 09:33:20 -0500 Robert Treat
<xzilla(at)users(dot)sourceforge(dot)net> wrote:
> On Sat, 2004-02-07 at 21:35, Palle Girgensohn wrote:
>> Hi,
>>
>> We use postgresql for rather large databases. For a typical
>> installation, a pg_restore takes a couple of hours, at least (the
>> dumpfiles are usually 2-4 gigabytes or so, including BLOBs). The
>> machines are expected to be up 24/7, so this dump/restore procedure
>> makes upgrading unpopular. Is there any (safe) way to speed this
>> process up?
>>
>> If pg_upgrade is not a good idea, how can I speed up pg_restore? Best
>> way to set things like fsync etc in postgresql.conf? Will it make a big
>> difference?
>>
>
> yes, setting fsync off should make a significant difference. I usually
> recommend it cause if there is a machine failure during restore I will
> want to start the process again anyway. Other items you should probably
> change are cranking up sort_mem significantly (if your restore is the
> only process running, let it take up most of the ram on the box) and you
> can increase check_point segments as well. HTH
Thanks, I'll try this.
Regards,
Palle
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-02-10 16:27:52 | Re: Upgrading from 7.2 to 7.4.1 on Redhat 7 |
Previous Message | scott.marlowe | 2004-02-10 16:12:40 | Re: hanging for 30sec when checkpointing |