On Fri, Apr 16, 2010 at 3:22 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Josh Kupershmidt <schmiddy@xxxxxxxxx> writes: >> name | current_setting | source >> ----------------------+-----------------+-------------------- >> vacuum_cost_delay | 200ms | configuration file >> vacuum_cost_limit | 100 | configuration file >> vacuum_cost_page_hit | 6 | configuration file >> >> It looks like the default which I have of autovacuum_vacuum_cost_limit >> = -1, which means it's inheriting the vacuum_cost_limit of 100 I had >> set. I'll try bumping vacuum_cost_limit up to 1000 or so. > > Actually I think the main problem is that cost_delay value, which is > probably an order of magnitude too high. The way to limit vacuum's > I/O impact on other stuff is to make it take frequent short delays, > not have it run full speed and then sleep a long time. In any case, > your current settings have got it sleeping way too much. Two WEEKS !!!?? Yup, I was going to turn vacuum_cost_delay down to 20. The two weeks was for the pg_catalog table which has bloated to 145 GB, I think. One of those manual VACUUMs I kicked off just finished, after 48 hours -- and that table was only 25 GB or so. I wasn't the one who set up this postgresql.conf, but I am stuck fixing things :/ -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
