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