Tom Lane wrote: > 4. At completion of ANALYZE, the regular tabstat machinery sends > off a tabstat message for the table, because guess what, ANALYZE did a > scan of that table, and there are t_blocks_fetched counts to report. > > 5. pgstat_recv_tabstat happily creates a table entry. (The pg_statio > counts in it are nonzero, even though the pg_stat counts aren't.) > > 6. Now, if you repeat the cycle, the stats collector will accept > the second PgStat_MsgAnalyze message, because this time there's > a stats table entry. > > This is a bit silly I guess --- we dropped the data but didn't actually > save any stats-table space. > > I'm inclined to think that the don't-create-a-table-entry behavior in > pgstat_recv_vacuum and pgstat_recv_analyze should just be dropped. > I'm dubious that it ever worked as intended. To have it work right > you'd need to suppress vacuum/analyze physical I/O from the tabstats > counts, which doesn't seem like an amazingly good idea. Moreover, > autovacuum is unlikely to issue vacuum or analyze against a table > that hasn't already got a stats-table entry, so the filter doesn't > seem likely to buy much if it did work. There might have been some > value in the idea back when cron-driven database-wide VACUUM ANALYZE > was the standard maintenance mechanism, but that's not the recommended > thing anymore.
I think this business about supressing pgstat entries started because of autovacuum. I wasn't too fond of the idea at the time. I wouldn't be opposed to ripping it out either. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
