Tom Lane wrote: > We could make it cleaner by inventing a function to clear out the cached > statistics within a transaction, perhaps "pg_stat_reset_snaphot()" or > some such name. If anyone thinks that that would be of general > usefulness, I'll see about making it happen.
During the development of the launcher/worker autovac separation, I thought a bit about how to handle stats invalidation. The launcher process needs to read the stat file every once in a while, but the worker doesn't care if the stats are very up to date. I came up with the idea of storing the stat hash in a particular memory context, and have a flag in pgstat.c that's reset when that context is reset. So each caller can define what's the appropriate lifetime. In launcher, stats would be reset once every main loop (after which an autovacuum_naptime sleep takes place, which means that the original coding of reading it every autovac iteration is kept). In worker, it's read only once, at the start of the process. And in backends (though I didn't implement it), stats could be stored in TopTransationContext and the flag reset in CommitTransaction and AbortTransaction. It would be quite easy to provide a function to reset stats within a transaction, by having the hash allocated in a context child of TopTransation. One problem is how to make sure that the flag is reset when the context is. If we had "cleanup callbacks" for memory contexts this would be trivial and robust. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
