Re: [HACKERS] now 6.4
От | The Hermit Hacker |
---|---|
Тема | Re: [HACKERS] now 6.4 |
Дата | |
Msg-id | Pine.BSF.3.96.980629214603.6863G-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: [HACKERS] now 6.4 (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] now 6.4
|
Список | pgsql-hackers |
On Mon, 29 Jun 1998, Bruce Momjian wrote: > > Now, I liked the idea that was presented about moving the > > database directories out of the way and then moving them back in after an > > initdb...is this not doable? What caveats are there to doing this? > > Individual database's will be missing fields added in the release upgrade, > > so if you want some of the v6.4 new features, you'd have to dump the > > individual database and then reload it, but if you don't care, you'd have > > some optimizations associated with the new release? > > We will move the old data files out of the way, run initdb, reload a > pg_dump with schema-only, then move the data files back into the proper > locations, and perhaps drop/recreate all indexes. They will have all > the features. They have just kept their raw data files. > > How long does re-indexing the tables take vs. reloading and re-indexing? Is re-indexing required? With the old indexes work with a new release, albeit slower? Or just not work at all? As for dropping/recreating all indices...that isn't really so bad, anyway...once all the data is there, th edatabase can go live...albeit *very* slow, in some cases, if I have 4 indices on a table, each one built should improve the speed of queries, but each build shouldn't limit the ability for the database to be up... Marc G. Fournier Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
В списке pgsql-hackers по дате отправления: