Re: db size

From: PFC <lists(at)peufeu(dot)com>
To: "Adrian Moisey" <adrian(at)careerjunction(dot)co(dot)za>, pgsql-performance(at)postgresql(dot)org
Subject: Re: db size
Date: 2008-04-14 09:18:19
Message-ID: op.t9lf4tvrcigqcu@apollo13.peufeu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> Hi
>
> 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?

I have a 2GB database, which dumps to a 340 MB file...
Two reasons :

- I have lots of big fat but very necessary indexes (not included in dump)
- Dump is compressed with gzip which really works well on database data.

If you suspect your tables or indexes are bloated, restore your dump to a
test box.
Use fsync=off during restore, you don't care about integrity on the test
box.
This will avoid slowing down your production database.
Then look at the size of the restored database.
If it is much smaller than your production database, then you have bloat.
Time to CLUSTER, or REINDEX, or VACUUM FULL (your choice), on the tables
that are bloated, and take note to vacuum those more often (and perhaps
tune the autovacuum).
Judicious use of CLUSTER on that small, but extremely often updated table
can also be a very good option.
8.3 and its new HOT feature are also a good idea.

In response to

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

Responses

  • Re: db size at 2008-04-14 09:21:59 from Adrian Moisey

Browse pgsql-performance by date

  From Date Subject
Next Message Adrian Moisey 2008-04-14 09:21:59 Re: db size
Previous Message Gaetano Mendola 2008-04-14 09:13:05 shared_buffers performance