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?"
In response to
pgsql-hackers by date
|Next:||From: Tomas Vondra||Date: 2010-12-19 19:27:00|
|Subject: Re: keeping a timestamp of the last stats reset (for a
db, table and function)|
|Previous:||From: Florian Pflug||Date: 2010-12-19 19:16:18|
|Subject: Re: pg_ctl and port number detection|