| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
| Cc: | Richard Huxton <dev(at)archonet(dot)com>, Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>, PostgreSQL - General ML <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: On-disk size of db increased after restore |
| Date: | 2010-09-01 20:59:20 |
| Message-ID: | 996.1283374760@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Richard Huxton's message of mi sep 01 16:39:55 -0400 2010:
>> OK - so not fillfactor and not some unicode-related padding. I can't see
>> how a 32 vs 64-bit architecture change could produce anything like a
>> doubling of database size.
> Depending on table schemas, why not? e.g. consider a table with a
> single bool column. It will waste 7 bytes on 8-byte MAXALIGN machine
> but only 3 on a 4-byte MAXALIGN machine.
Yeah, but after you account for row header overhead, the worst-case
percentage bloat still should be a lot less than 2X.
It would help if Devrim could break down the bloat to the level of
individual tables/indexes.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2010-09-01 21:01:01 | Re: postgreSQL problem |
| Previous Message | Alvaro Herrera | 2010-09-01 20:50:36 | Re: On-disk size of db increased after restore |