>
> 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?
Vadim is changing the index format for 6.4.
> 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...
Doesn't index creation lock the table?
--
Bruce Momjian | 830 Blythe Avenue
maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026
+ If your life is a hard drive, | (610) 353-9879(w)
+ Christ can be your backup. | (610) 853-3000(h)
