Re: pg_Restore - Mailing list pgsql-general

From Chris Travers
Subject Re: pg_Restore
Date
Msg-id CAKt_Zfty6HDmEhU+-Jue+s8Q5u8vfPJrbQnNA5O4ROhtpWXKCQ@mail.gmail.com
Whole thread Raw
In response to Re: pg_Restore  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Responses Re: pg_Restore  (bhanu udaya <udayabhanu1984@hotmail.com>)
List pgsql-general


On Mon, Jan 21, 2013 at 3:39 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
bhanu udaya wrote:
> I tried with all the below options. It approximatly takes 1 hour 30 minutes for restoring a 9GB
> database.  This much time can not be affordable as the execution of test cases take only 10% of this
> whole time and waiting 1 hour 30 minutes after every test case execution is alot for the team.  Kindly
> let me know if we can reduce the database restoration time .

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?

Also for test cases, my preferred way is to put every test case in a transaction that cannot commit.  This way the tests are safe to run on production environments.  See pgTAP for one possibility here if you are testing stored procedures.  (Application code we run through wrappers that filter out commits.) 

But also the template approach is a good one fi you cannot guarantee that the tests always role back.

Best Wishes,
Chris Travers

pgsql-general by date:

Previous
From: dinesh kumar
Date:
Subject: Re: pg_Restore
Next
From: Marcel van Pinxteren
Date:
Subject: Re: Case insensitive collation