Hi, For some times, we have a vacuuming process on a specific table that goes slower and slower. In fact, it took some 3 minutes a month ago, and now it take almost 20 minutes. But, if one day it take so many time, it is possible that on the day after it will only take 4 minutes... I know the table in concern had 450000 tuples two months ago and now has more than 700000 tuples in it. I wonder vacuum verbose would tell me if fsm parameters were not too badly configured, but I can't get the 4 last lines of the output... Is there another way to get these info ? Or is it a parameter badly configured ? For information, it's on AIX, PG8.1.9. Some configuration parameters : client_min_messages : notice log_error_verbosity : default log_min_error_statement : panic log_min_messages : notice. Whats's more, I wonder what we could monitor to get some explanation of the recent time increase, and then have a quite-sure way of configuring the server. I have to say the database is hosted, accessed in production on a 24/7 basis and then every change in configuration has to be scheduled. Some more information you may ask: chackpoint_segments : 32 checkpoint_timeout : 180 checkpoint_warning : 30 wal_buffers : 64 maintenance_work_mem : 65536 max_fsm_pages : 400000 max_fsm_relations : 1000 shared_buffers : 50000 temp_bufers : 1000 We also have 4Gb RAM. Isn't checkpoint_segments too low as all files in pg_xlogs seem to be recycled within a few minutes. (In fact among the 60 files, at least 30 have been modified during the few minutes of that particular vacuum). Thanks for any advice you could give me. Best regards, -- Stéphane SCHILDKNECHT Président de PostgreSQLFr http://www.postgresqlfr.org ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your message can get through to the mailing list cleanly
