Re: [HACKERS] now 6.4

On Thu, 11 Jun 1998, Vadim Mikheev wrote:

> Bruce Momjian wrote:
> >
> > So we will just need to re-create indexes.  Sounds OK to me, but
> > frankly, I am not sure what the objection to dump/reload is.
>
> It takes too long time to reload big tables...

    I have to agree here...the one application that *I* really use
this for is an accounting server...any downtime is unacceptable, because
the whole system revolves around the database backend.

    Take a look at Michael Richards application (a search engine)
where it has several *million* rows, and that isn't just one table.
Michael, how long would it take to dump and reload that?

    How many ppl *don't* upgrade because of how expensive it would be
for them to do, considering that their applications "work now"?

    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?

 Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org