Re: pg_Restore

From: dinesh kumar <dineshkumar02(at)gmail(dot)com>
To: "bhanu udaya *EXTERN*" <udayabhanu1984(at)hotmail(dot)com>
Cc: Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at>, Magnus Hagander <magnus(at)hagander(dot)net>, François Beausoleil <francois(at)teksol(dot)info>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_Restore
Date: 2013-01-21 12:15:35
Message-ID: CALnrH7qMSW6yaxLyhZRdsn3rKK6aCtSmF2UuMDBzsCB9RJ3rzQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-support pgsql-general

Hi Bhanu,

Yes, below is the faster approach to follow.

I don't know if that helps, but have you tried creating a template database
> and doing DROP DATABASE xxx; CREATE DATABASE xxx TEMPLATE mytemplate;
> instead of restoring a dump every time?
>
> Maybe that is faster.
>
>
If you are trying to take the dump from one cluster and restoring it in
another cluster, then make sure your pg_restore use parallel option "-j"
and also follow the parameters what Raghav said and tune WAL_BUFFERS to
some 32 to 64 MB value. And also if possible, keep your dump file into
another partition than the PGDATA which can improve the I/O balance.

Thanks.

Best Regards,
Dinesh
manojadinesh.blogspot.com

In response to

Browse pgadmin-support by date

  From Date Subject
Next Message Chris Travers 2013-01-21 12:16:19 Re: pg_Restore
Previous Message Martin French 2013-01-21 11:46:37 Re: Editable resultset

Browse pgsql-general by date

  From Date Subject
Next Message Chris Travers 2013-01-21 12:16:19 Re: pg_Restore
Previous Message Albe Laurenz 2013-01-21 11:39:00 Re: pg_Restore