Re: pg_Restore

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: pg_Restore
Дата
Msg-id CAKt_Zfty6HDmEhU+-Jue+s8Q5u8vfPJrbQnNA5O4ROhtpWXKCQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_Restore  (Albe Laurenz <laurenz.albe@wien.gv.at>)
Ответы Re: pg_Restore  (bhanu udaya <udayabhanu1984@hotmail.com>)
Список 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 по дате отправления:

Предыдущее
От: dinesh kumar
Дата:
Сообщение: Re: pg_Restore
Следующее
От: Marcel van Pinxteren
Дата:
Сообщение: Re: Case insensitive collation