Re: Where does data in pg_stat_user_tables come from?
От | Guillaume Lelarge |
---|---|
Тема | Re: Where does data in pg_stat_user_tables come from? |
Дата | |
Msg-id | 4C9269AF.8070002@lelarge.info обсуждение исходный текст |
Ответ на | Re: Where does data in pg_stat_user_tables come from? (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-performance |
Le 16/09/2010 20:39, Josh Berkus a écrit : > >> It's been pure nonsense in this thread. Please show an example of >> what's not working. > > 1) Init a postgresql 8.3 with autovacuum disabled. > > 2) Load a backup of a database into that PostgreSQL. > > 3) Check pg_stat_user_tables. n_live_tup for all tables will be 0. > > 4) VACUUM ANALYZE the whole database. > > 5) n_live_tup will *still* be 0. Whereas reltuples in pg_class will be > reasonable accurate. > Did all your steps (except the fourth one). Works great (meaning n_live_tup is updated as it should be). I have to agree with Alvarro, this is complete nonsense. VACUUM ANALYZE doesn't change the pg_stat_*_tables columns value, the stats collector does. If your n_live_tup didn't get updated, I'm quite sure you have track_counts to off in your postgresql.conf file. >> Um ... it updates the last_autovacuum and last_autoanalyze columns, >> but the others are not its responsibility. > > Right. I'm contending that ANALYZE *should* update those columns. The postgres process executing ANALYZE surely sent this information to the stats collector (once again, if track_counts is on). Tried it tonight, works great too. > Current behavior is unintuitive and makes the stats in > pg_stat_user_tables almost useless, since you can never get even > approximately a coherent snapshot of data for all tables. > Get a look at your track_count setting. -- Guillaume http://www.postgresql.fr http://dalibo.com
В списке pgsql-performance по дате отправления: