[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OSM-dev] [Maposmatic-dev] Re: Growth of on-disk size of OSM databas
Re: [OSM-dev] [Maposmatic-dev] Re: Growth of on-disk size of OSM database
Wed, 14 Jul 2010 13:14:09 +0200
On Wed, 2010-07-14 12:56:22 +0200, Thomas Petazzoni <address@hidden> wrote:
> On Wed, 14 Jul 2010 12:26:57 +0200 Frederik Ramm <address@hidden> wrote:
> > Depends on what you define as "same result". If you make a full dump
> > of your PostgreSQL tables and then re-import that, you will be
> > somewhere at 122 GB or so. You could also do a "vacuum full" to
> > achieve the same result, or do a fresh import. But if you make a
> > comparison of the files in your /var/lib/postgresql directory, these
> > will not be the same as if you were to do a new import. The normal
> > vacuuming that PostgreSQL does is insufficient to release some
> > allocated space and later freed space in the data files, that's why
> > your database is larger that it would have to be. Your select results
> > will look the same.
> Unfortunately, as far as I understand, doing a "vacuum full" is going
> to block accesses to the database for a fairly long amount of time
> (days ?). So the best solution is probably to regularly (every few
> months) do a new full import in a separate database, and switch to this
> new database when the full import is completed.
VACUUM FULL will block. If you have enough disk space, you'd
alternativel start a hugh transaction doing a
CREATE TABLE xxxxx_new AS SELECT * FROM xxxxx;
for every existing table. (Maybe you need to handle some more objects
manually, have a look at the schema definition dump beforehand). When
all that is done, DROP the old tables and rename the new ones to the
old names. That might be faster than re-importing everything.
Jan-Benedict Glaw address@hidden +49-172-7608481
Signature of: Lauf nicht vor Deinem Glück davon:
the second : Es könnte hinter Dir stehen!
Description: Digital signature