On 02/23/2013 05:10 PM, Jeff Janes wrote:
On Saturday, February 23, 2013, Stefan Andreatta wrote:
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.
Hi Stefan,
Sorry, I got tunnel vision about the how the threshold was computed,
and forgot about the thing it was compared to. There is a "secret"
data point in the stats collector called changes_since_analyze. This
is not exposed in the pg_stat_user_tables. But I think it should be
as I often have wanted to see it.
Cheers,
Jeff
Sounds like a very good idea to me - any way I could help to make such a
thing happen?
Stefan
