Re: [HACKERS] now 6.4 - Mailing list pgsql-hackers

From The Hermit Hacker
Subject Re: [HACKERS] now 6.4
Date
Msg-id Pine.BSF.3.96.980629214603.6863G-100000@thelab.hub.org
Whole thread Raw
In response to Re: [HACKERS] now 6.4  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] now 6.4
List 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 by date:

Previous
From: Vince Vielhaber
Date:
Subject: Re: [HACKERS] now 6.4
Next
From: The Hermit Hacker
Date:
Subject: Re: [HACKERS] regular expressions from hell