Skip site navigation (1) Skip section navigation (2)

Re: Fastest DB restore options

From: ogjunk-pgjedan(at)yahoo(dot)com
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Fastest DB restore options
Date: 2007-02-23 06:42:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin

Yes, In remember discussions about (f)sync config.  Can anyone comment on whether turning fsync off for a restore into 8.2.3:
1) is advisable
2) will make the restore faster

If the OS and FS matter, this is on a Fedora Core3 Linux with kernel 2.6.9 and the ext3 journaling FS.


----- Original Message ----
From: Marco Bizzarri <marco(dot)bizzarri(at)gmail(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Sent: Thursday, February 22, 2007 3:47:37 PM
Subject: Re: [ADMIN] Fastest DB restore options

On 2/22/07, ogjunk-pgjedan(at)yahoo(dot)com <ogjunk-pgjedan(at)yahoo(dot)com> wrote:
> Hello,
> I have a fairly large DB to dump and restore as fast as possible.  I'm moving from 8.0.3 to 8.2.3! :)
> I normally dump with these options:
>   -d MyDB --clean --inserts --column-inserts --format=P
> But the last time I tried that, the restore took foreeeeeeeeeeeeeever.  So I'm looking for the fastest way to import data from the old DB to the new one.  Judging from pg_dump man page the following should be the fastest dump & restore:
>   -d MyDB --format=c --ignore-version
> Is there anything else I can do to make the restore as fast as possible?
> Thanks,
> Otis

I'm not sure it is advisable, or it is even faster in current
implementation. In older ones, if you configure postgresql not to sync
after each write, you could end in a faster restore. Since this is a
restore, after all, if lights goes out, you can always throw all away
and start from scratch...


pgsql-admin by date

Next:From: Peter EisentrautDate: 2007-02-23 07:27:45
Subject: Re: pg_hba.conf multiple auth_metods question
Previous:From: Jim NasbyDate: 2007-02-22 22:57:54
Subject: Re: Priorities for users or queries?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group