Tom Lane wrote:
> Actually, there's another problem here: if we do have row-level stats
> turned on, a manual "VACUUM" command will still cause the set of tables
> listed in the stats file to grow to include every table in the DB,
> whether or not anything interesting is happening to that table. I think
> this is probably undesirable. I'm tempted to change pgstat_recv_vacuum
> and pgstat_recv_analyze so that they will not create new hash entries,
> but only insert the row count if the hash entry already exists. I am a
> bit worried that I might be missing something about possible
> interactions with autovacuum though. I see that autovac skips vacuuming
> tables that have no hash entry ... is there some circular reasoning
> going on there?
The idea was that autovac should skip tables for which it doesn't have
info, because it can't decide and we chose to err on the side of
caution. However, after a vacuum or analyze we do have info about the
table, which is what we store in the pgstat_recv functions
inconditionally. Thus the next autovacuum is able to make an informed
decision about this table.
The principles are: 1) store as much information as possible,
2) autovacuum should act iff it has information.
I don't think this is a bug, but I'm not dead set on it if you want to
change this behavior.
--
Alvaro Herrera http://www.amazon.com/gp/registry/DXLWNGRJD34J
"The first of April is the day we remember what we are
the other 364 days of the year" (Mark Twain)
