Re: db size

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: Adrian Moisey <adrian(at)careerjunction(dot)co(dot)za>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: db size
Date: 2008-04-14 13:12:12
Message-ID: 20080414091212.f73eb101.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

In response to Adrian Moisey <adrian(at)careerjunction(dot)co(dot)za>:
>
> We currently have a 16CPU 32GB box running postgres 8.2.
>
> When I do a pg_dump with the following parameters "/usr/bin/pg_dump -E
> UTF8 -F c -b" I get a file of 14GB in size.
>
> But the database is 110GB in size on the disk. Why the big difference
> in size? Does this have anything to do with performance?

In a dump, indexes are a single command. In the actual database, the
indexes actually contain all the data the indexes require, which can
be substantially more in size than the command to create the index.

Additionally, a running database has a certain amount of wasted space.
If you're running vacuum on a proper schedule, this won't get out of
hand. Read this page to understand better:
http://www.postgresql.org/docs/8.1/static/maintenance.html

And lastly, I expect that the pg_dump format is able to do more aggressive
compression than the running database.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran(at)collaborativefusion(dot)com
Phone: 412-422-3463x4023

In response to

  • db size at 2008-04-14 06:29:56 from Adrian Moisey

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Smith 2008-04-14 15:42:50 Re: shared_buffers performance
Previous Message Richard Huxton 2008-04-14 11:25:45 Re: shared_buffers performance