Skip site navigation (1) Skip section navigation (2)

Re: 7.4 <-> 8.0

From: Guido Barosio <gbarosio(at)gmail(dot)com>
To: snelling(at)email(dot)marc(dot)usda(dot)gov
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: 7.4 <-> 8.0
Date: 2005-09-16 16:26:56
Message-ID: f7f6b4c705091609264108df2a@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
Hi Warren,

Actually, in my particular case (old pgsql version, and a big db), reindex 
and vacuum full are extremely expensive in operation costs,
and I am running them myself on planned conditions. But that's my case. 
Scripting this, with a cron hand, 
would be ok, and I guess that is something you will prolly find out there. 

The reindex process is something to watch at, and not to leave running 
during the night, without some bird eye on it,
at least on my scenery.

Best wishes,
Guido.


On 9/16/05, Warren Snelling <snelling(at)email(dot)marc(dot)usda(dot)gov> wrote:
> 
> Guido,
> 
> Thanks for the pointers. I have routinely vacuumed the db, but not
> using full.
> 
> By itself, the "vacuum full" run overnight did not free the space I was
> expecting - du still showed the old database taking about 12 Gb disk,
> and the fresh databases taking about 6.5 Gb. Running "reindex" on one
> large table freed ~5 Gb, so the old db now takes 7 Gb. Reindexing the
> remaining tables should get the databases to the same size.
> 
> Would you suggest scripting the vacuum full / reindex process to run
> periodically (once a week or so)? Right now disk space on this machine
> is not an issue, but vacuuming and reindexing occasionally should keep
> the db from consuming too much excess space.
> 
> Thanks again,
> warren
> 
> > 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(at)gmail(dot)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(at)email(dot)marc(dot)usda(dot)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.
> 
> 


-- 
"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.

In response to

pgsql-admin by date

Next:From: Peter ChildsDate: 2005-09-16 16:30:03
Subject: Re: 7.4 <-> 8.0
Previous:From: Lane Van IngenDate: 2005-09-16 16:25:06
Subject: Re: silent installation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group