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