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) ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
