Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have a strange problem. The size of my postgresql (8.3) is increasing. So I made a dump and then cleaned up the database and then re-imported the dump. The database size was reduced by roughly 50%.
Some infomation:
(1) AUTOVACUUM and REINDEX are running regularly in background.
(2) Database encoding is ASCII.
(3) Database location: /database/pgsql/data
(4) System: Suse-Ent. 10.
Any hints are appreciated
If the dead tuples have stacked up beyond what can be accounted for in
max_fsm_pages, a regular VACUUM will not be able to free everything. The end result is that the database will grow larger and larger over time as dead space continues to accumulate. Running a VACUUM FULL should fix this problem. Unfortunately it can take a very long time on a large database.If you’re running into this problem frequently, you either need to vacuum more often (autovacuum can help here) or increase the
max_fsm_pagessetting. When running VACUUM VERBOSE it will tell you how many pages were freed and give you a warning ifmax_fsm_pageswas exceeded, this can help you determine what this value should be. See the manual for more information. http://www.postgresql.org/docs/8.3/static/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-FSMFortunately, 8.4’s visibility map resolves this issue. Despesz has a great story on the subject as usual: http://www.depesz.com/index.php/2008/12/08/waiting-for-84-visibility-maps/