From: | Stuart Brooks <stuartb(at)cat(dot)co(dot)za> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: autovacuum not freeing up unused space on 8.3.0 |
Date: | 2008-02-26 09:41:04 |
Message-ID: | 47C3DEB0.5050607@cat.co.za |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>> ERROR: canceling autovacuum task
>> CONTEXT: automatic vacuum of table "metadb.test.transactions"
>
> Are these happening regularly? They indicate that something is
> happening on the table that collides with what autovacuum needs to do,
> and autovacuum defers its task. For this to happen you need to be doing
> ALTER TABLE or similar however; normal UPDATE/INSERT/DELETE should not
> cause autovacuum to cancel itself.
>
I am not using an ALTER table command but I am doing periodic ANALYZEs
to evaluate the table size. Could this be causing the problem? I notice
that stopping the ANALYZE calls appears to eliminate the canceled
autovacuum.
What concerns me is that once the size has grown, even a VACUUM FULL
doesn't recover the space. Regular external VACUUMs keep the table at
around 10MB but if I use autovacuum and it grows to 40MB, a VACUUM FULL
will only get it down to 35MB. Is it possible that a canceled autovacuum
could result in permanently lost space?
Out of interest, what kind of fragmentation overhead should I expect if
I have a table in which I maintain a fixed number of rows. eg. A 20000
row table which is 6MB before rows are wrapped out will obviously use a
larger disk footprint as rows are added and deleted. Anyone have a rule
of thumb which works for them?
Thanks for the response,
Stuart
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Lau | 2008-02-26 09:44:27 | Re: syntax error at or near "PROCEDURAL" |
Previous Message | Magnus Hagander | 2008-02-26 09:30:19 | Re: syntax error at or near "PROCEDURAL" |