Re: autovacuum not freeing up unused space on 8.3.0
От | Stuart Brooks |
---|---|
Тема | Re: autovacuum not freeing up unused space on 8.3.0 |
Дата | |
Msg-id | 47C3DEB0.5050607@cat.co.za обсуждение исходный текст |
Ответ на | Re: autovacuum not freeing up unused space on 8.3.0 (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: autovacuum not freeing up unused space on 8.3.0
Re: autovacuum not freeing up unused space on 8.3.0 |
Список | 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
В списке pgsql-general по дате отправления: