Eelke is almost certainly correct that your locking is blocking autovacuum. Autovacuum is designed to give way to user activity, deliberately. If those tables are locked, autovacuum cannot vacuum them.
For posterity, however, I wanted to give an example set of settings for hyper-aggressive autovacuum, since the settings you gave don't quite do it. Note that making autovacuum more aggressive is unlikely to solve your problem, however. Also note that the default autovacuum settings are based on running over 200 test runs using DBT2 seeking an optimal combination of settings, so the defaults should be assumed to be good unless you have a solid reason to think otherwise, or unless your database is significantly outside the mainstream for OLTP databases (e.g. a tiny database which gets 10K updates per second, or a 3TB data warehouse).
First, turn on logging so you can check up on whether autovacuum is doing what you think it is:
log_autovacuum_min_duration = 0
Then let's make more autovac workers and have them check tables more often:
autovacuum_max_workers = 6
autovacuum_naptime = 15s
Let's lower the thresholds for auto-vacuum and auto-analyze to trigger sooner:
autovacuum_vacuum_threshold = 25
autovacuum_vacuum_scale_factor = 0.1
autovacuum_analyze_threshold = 10
autovacuum_analyze_scale_factor = 0.05
Then let's make autovacuum less interruptable, so it completes faster, but at the cost of having a greater impact on concurrent user activity:
autovacuum_vacuum_cost_delay = 10ms
autovacuum_vacuum_cost_limit = 1000
There's your full program for generically aggressive autovacuum, which might be apppropriate for a small database getting a very high rate of updates, but might have too great of an impact on concurrent user activity.
Also, note that autovacuum parameters can be adjusted per table, which is almost always a better answer for needing to adjust autovacuum's behavior.
Again, though, it's unlikely to address your real problem.
I cannot check how it is in 9.2, but I had this exact same difficulty in 9.3.
The problem is that initdb is installed. It just isn't in your path.
What happens when you run these two commands?
updatedb
locate initdb
That's how I found it. Then, all I had to do was execute :
/usr/lib/postgresql/9.3/bin/initdb
You'll probably find that it's just the same in 9.2.
Best Answer
1) If you don't count your own time as a resource, then you should always be able to hand-craft a vacuum schedule which uses fewer total resources than autovacuum does. If you do count your own time, this is almost surely not worthwhile.
2) Other than manually or algorithmically turning it on or off, no. Nor would it make sense to do that. A database that sees only a very steady predictable load with no unusual spikes still needs vacuuming. However, if you do spend a lot of time coming up with a highly optimized hand-crafted vacuum schedule, then autovacuum will never have any vacuuming to do except under unusual activity not anticipated in your custom schedule; so in this sense what you want is automatically the case.
3) It isn't clear whether you mean when an autovacuum worker will start up in a given database, or when any given table will start to be vacuumed. The first is determined by autovacuum_naptime, unless autovacuum_max_workers becomes the limiting factor. The second is determined by when the table crosses the threshold, with a granularity of autovacuum_naptime, except when autovacuum_max_workers becomes the limiting factor. How accurately you can predict this depends on how steady the activity on that table is, and whether the vacuum tasks are generally overloaded or are mostly idle.