From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Devrim GÜNDÜZ <devrim(at)gunduz(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Richard Huxton <dev(at)archonet(dot)com>, PostgreSQL - General ML <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: On-disk size of db increased after restore |
Date: | 2010-09-03 13:41:00 |
Message-ID: | 21406.1283521260@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= <devrim(at)gunduz(dot)org> writes:
> On Thu, 2010-09-02 at 13:22 -0400, Tom Lane wrote:
>> Devrim, have you identified yet which tables have the bloat? Are they
>> the ones with tweaked autovacuum parameters?
> That's it.
> On prod server, that table consumes 50 GB disk space, and on the backup
> machine, it uses 148 GB. I applied custom autovac settings only to that
> table.
> This is 8.4.4 btw...
OK, so the bug is fixed, but you still have fillfactor = 0 on the
affected table.
> So, what should I do now?
Explicitly reset the table's fillfactor to default (100), then
you'll need to CLUSTER or VACUUM FULL or something.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Wagner | 2010-09-03 13:42:36 | Problems (bug?) with the Postgres 8.4.4 optimizer, 2nd try |
Previous Message | A. Kretschmer | 2010-09-03 13:38:01 | Re: alter column to inet get error. |