Re: 8.0.3 pg_autovacuum doesn't clear out stats table?

>
>> Third: Are you seeing in the autovacuum log that autovacuum is
>> actually trying to vacuum tables? Turn up the debugging to -d2 that
>> should give you some more info as to why autovac is (or is not) doing
>> what it's doing.
>>
> I will turn it on and take a look. I am guessing it will tell me that
> for whatever reason it isn't actually doing anything to the pg_catalog
> tables ...

So I ran pg_autovacuum with -d 2 on the command line and I see this at
startup

Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: Printing command_args
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->host=(null)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->port=(null)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->username=(null)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->password=(null)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->logfile=(null)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->daemonize=0
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->sleep_base_value=300
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->sleep_scaling_factor=2.000000
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->vacuum_base_threshold=1000
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->vacuum_scaling_factor=2.000000
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->analyze_base_threshold=500
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->analyze_scaling_factor=1.000000
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->av_vacuum_cost_delay=(default)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->av_vacuum_cost_page_hit=(default)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->av_vacuum_cost_page_miss=(default)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->av_vacuum_cost_page_dirty=(default)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->av_vacuum_cost_limit=(default)
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: args->debug=2

<snip> This is the output for the pg_statistic table in the database
that is tiny and is used for testing and has never been "vacuum full" as
far as I know:

Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: table name: gems."pg_catalog"."pg_statistic"
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: relid: 16408; relisshared: 0
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: reltuples: 709086.000000; relpages: 78341
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: curr_analyze_count: 500680; curr_vacuum_count: 500680
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: last_analyze_count: 500680; last_vacuum_count: 500680
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
INFO: analyze_threshold: 709586; vacuum_threshold: 1419172
Feb 23 18:46:42 helm daemon_pg_autovacuum: [2006-02-23 18:46:42 GMT]
DEBUG: added table: gems."pg_catalog"."pg_statistic"

<snip>

The tuples and thresholds for the pg_statistic table look like they
might be the reason it doesn't get vacuumed. The question is, why does
the reltuples on the stats table keep climbing until you do a vacuum
full, at which point they return to (near) zero? No matter what
threshold and scale I set, I am not going to get that table vacuumed
because it's delete/update rate are 0 (it's always inserted to I believe).

After that I just see:
DEBUG: 1 All DBs checked in: 478378 usec, will sleep for 300 secs.
DEBUG: 2 All DBs checked in: 73336 usec, will sleep for 300 secs.

Implying that there isn't anything doing right now (the staff are all
gone, so there is no activity on the database as I type, and we know it
won't vacuum the pg_statistics table due to thresholding).

What am I missing?

Thanks,
Robin