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)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: proposal : cross-column stats
Следующее
От: Tom Lane
Дата:
Сообщение: Re: keeping a timestamp of the last stats reset (for a db, table and function)