Re: suggestion

Поиск
Список
Период
Сортировка
Искать
От
Jim C. Nasby
Тема
Re: suggestion
Дата
Msg-id
20060224000241.GQ2068@pervasive.com
Ответ на
Re: suggestion (Jan Cruz)
Список
Дерево обсуждения
suggestion "Jan Cruz" <malebug@gmail.com>
Re: suggestion Michael Glaesemann <grzm@myrealbox.com>
Re: suggestion "Jan Cruz" <malebug@gmail.com>
Re: suggestion "Jim C. Nasby" <jnasby@pervasive.com>
Re: suggestion Andrew Dunstan <andrew@dunslane.net>
Re: suggestion Michael Glaesemann <grzm@myrealbox.com>
Re: suggestion Tom Lane <tgl@sss.pgh.pa.us>
Re: suggestion "Jan Cruz" <malebug@gmail.com>
Re: suggestion Christopher Kings-Lynne <chriskl@familyhealth.com.au>
Re: suggestion "Jan Cruz" <malebug@gmail.com>
Re: suggestion Lukas Smith <smith@pooteeweet.org>
On Fri, Feb 24, 2006 at 07:58:38AM +0800, Jan Cruz wrote:
> On 2/24/06, Michael Glaesemann  wrote:
> --schema-only flag is the equivalence of -s
> 
> I also want an option that would exclude  "CREATE INDEX "  whenever
> a schema is being dump

At least on my small test database, all the CREATE INDEX commands are
one-liners. This means it would be trivial to exclude them with
grep -v 'CREATE INDEX, or grab just them with grep 'CREATE INDEX'. I'd
just stick the greps in between cat and psql -f -.

> The reason for this is that whenever I tried to migrate database
> whenever I restore a schema with indexes and then
> restore the data separately it took more or less 24 hours instead of
> the usual 1 hour more or less.
> 
> For example let say I want to use this particular schema from the test
> server
> since the stored functions and/or views are already updated
> 
> and then my data would come from the production server which has a different
> 
> version of postgres and the schema (particularly the stored functions/views)
> that
> would is already deprecated from the test server.
> 
> So I just need to dump the schema from the test server without the indexes
> and restore the new schema to a new database/server and restore the dump
> from the production server to the new database/server.
> 
> I hope I explain my side properly

-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

В списке pgsql-hackers по дате отправления
От: Jan Cruz
Дата:
Сообщение: Re: suggestion
От: Andrew Dunstan
Дата:
Сообщение: Re: fsutil ideas
FAQ