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