Re: 7.4 <-> 8.0 - Mailing list pgsql-admin

From Guido Barosio
Subject Re: 7.4 <-> 8.0
Date
Msg-id f7f6b4c705091513473b7def79@mail.gmail.com
Whole thread Raw
In response to Re: 7.4 <-> 8.0  (Guido Barosio <gbarosio@gmail.com>)
Responses Re: 7.4 <-> 8.0
List pgsql-admin
still thinking on this topic, read about the REINDEX command, that will recreate your indexes, per table or per database.
 
Regards,
Guido.

 
On 9/15/05, Guido Barosio <gbarosio@gmail.com> wrote:
Hi Warren
 
On the space issue, seems at a first sight that the old db needs a vacuum full to free some room.
Try to identify your biggest tables, isolate the vacuum against them, and then escalate to the whole db, with a vacuum full.
 
Thinking that you should double check the vacuum documentation, to understand better which are the effects of the different vacuum modes. This will clear out your doubts on why such amount of space is being allocated, but not being used.
 
My two cents there.
 
Best wishes,
Guido.
 
On 9/15/05, Warren Snelling <snelling@email.marc.usda.gov > wrote:
All,

Couple questions from to a recent upgrade from 7.4.8 to 8.0.3.  With
servers for both versions running on the same machine,

  pg_dumpall -p 5432 -c | psql -p 5433 template1

appears to have migrated the databases smoothly.  At least I didn't
notice any errors in the process, and all the data appears to be there.

The one troubling thing is the new 8.0 databases take about half the
disk space as the 7.4 databases.  Similar dump | psql to recreate the
databases on other machines running 7.4.7 and 7.4.8 show the same thing
- the fresh copies take half the space of the old.  What might be
happening with the old db, so it takes so much more space?  Could half
the data be missing?

What's the best way to move data from 8.0 to 7.4?  The 8.0 pg_dump
writes a dump that doesn't restore with 7.4 psql, and 7.4 pg_dump
doesn't seem to handle an 8.0 database.  At least I haven't found the
right switches...

Thanks,
warren


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster



--
"Adopting the position that you are smarter than an automatic
optimization algorithm is generally a good way to achieve less
performance, not more" - Tom Lane.



--
"Adopting the position that you are smarter than an automatic
optimization algorithm is generally a good way to achieve less
performance, not more" - Tom Lane.

pgsql-admin by date:

Previous
From: Guido Barosio
Date:
Subject: Re: Reg:Database and Table information
Next
From: FBaron@co.belcorp.biz
Date:
Subject: pgadmin- error relation pg_user