Re: [HACKERS] now 6.4

> 
> 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)