Dne 19.12.2010 17:26, Tom Lane napsal(a): > That seems like quite a bizarre definition. What I was envisioning was > that we'd track only the time of the last whole-database stats reset.
Well, but that does not quite work. I need is to know whether the snapshot is 'consistent' i.e. whether I can compare it to the previous snapshot and get meaningful results (so that I can perform some analysis on the difference). And by 'consistent' I mean that none of the counters was reset since the previous snapshot. The most obvious and most flexible way to do this is keeping track of the last reset for each of the counters, which is exactly what I've done in the patch. The other possibility I've offered in my previous post is to keep just a per-database timestamp, and set it whenever some stats in the database are reset (table/index/function counters or all stats). It definitely is not as flexible as the previous solution, but it gives me at least some info that something was reset. But I'd have to throw away the whole snapshot - in the previous case I could do analysis at least on the counters that were not reset. The solution you've offered - keeping only the per-database timestamp, and not updating it when a table/index/function stats are reset, that's completely useless for me. It simply does not provide an answer to the question "Is this snapshot consistent?" Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers