Re: keeping a timestamp of the last stats reset (for a db, table and function)
От | Tomas Vondra |
---|---|
Тема | Re: keeping a timestamp of the last stats reset (for a db, table and function) |
Дата | |
Msg-id | 4D0E7F1D.9000007@fuzzy.cz обсуждение исходный текст |
Ответ на | Re: keeping a timestamp of the last stats reset (for a db, table and function) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: keeping a timestamp of the last stats reset (for a db, table and function)
|
Список | pgsql-hackers |
Dne 19.12.2010 20:28, Tom Lane napsal(a): > Tomas Vondra <tv@fuzzy.cz> writes: >> 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). > > Oh, I see. Yeah, if that's what you want it for then partial resets > have to change the timestamp too. I guess if we are careful to document > it properly, this won't be too horrid. > > regards, tom lane > Well, maybe. I'd prefer the timestamp for each item, as that allows me to determine which stats were not reset and analyze at least those data. Plus I won't have time to write the other patch for at least a week, so let's see whether there are serious objections agains the current patch. I've never had problems with the pgstat.dat file, but I understand others might, although this adds "just 8 bytes" to each item. regards Tomas
В списке pgsql-hackers по дате отправления: