Thanks Jeff, that helped a lot (as did a careful rereading of
http://www.postgresql.org/docs/9.1/static/monitoring-stats.html
and
http://www.postgresql.org/docs/9.1/static/catalog-pg-class.html
;-)
However, to estimate whether autoanalyze should be triggered,
I am still missing something: the analyze threshold is
compared to the "total number of tuples inserted, updated, or
deleted since the last
ANALYZE." (according to
http://www.postgresql.org/docs/9.1/static/routine-vacuuming.html).
pg_stat_user_tables.n_live tup - pg_class.reltuples should
give something like the sum of rows inserted minus rows
deleted since the last ANALYZE. But according to the
documentation we would need the sum of those values. And we
are still missing a number for rows updated since the last
analyze. pg_stat_usert_tables. n_dead_tup, on the other hand,
is only set back by successful VACUUM. autoanalyzing a table
with more than 10% dead rows would therefore keep autoanalyze
in a loop until the ratio rises beyond 20% (default
configuration) and autovacuum kicks in. So that wouldn't make
a lot of sense.
