Re: 7.4 <-> 8.0

Поиск
Список
Период
Сортировка
От Warren Snelling
Тема Re: 7.4 <-> 8.0
Дата
Msg-id 1126886236.12350.106.camel@localhost
обсуждение исходный текст
Ответ на Re: 7.4 <-> 8.0  (Guido Barosio <gbarosio@gmail.com>)
Ответы Re: 7.4 <-> 8.0  (Guido Barosio <gbarosio@gmail.com>)
Re: 7.4 <-> 8.0  (Scott Marlowe <smarlowe@g2switchworks.com>)
Re: 7.4 <-> 8.0  (Peter Childs <bluedragon@blueyonder.co.uk>)
Re: 7.4 <-> 8.0  (Peter Childs <bluedragon@blueyonder.co.uk>)
Список pgsql-admin
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@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 по дате отправления:

Предыдущее
От: Scott Marlowe
Дата:
Сообщение: Re: Replication
Следующее
От: "Lane Van Ingen"
Дата:
Сообщение: Re: silent installation