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 4D138B49.6010108@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)  (Robert Haas <robertmhaas@gmail.com>)
Re: keeping a timestamp of the last stats reset (for a db, table and function)  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-hackers
Dne 20.12.2010 00:03, Tom Lane napsal(a):
> I wrote:
>> That is not the number of interest.  The number of interest is that it's
>> 8 bytes added onto a struct that currently contains 11 of 'em; in other
>> words a 9% increase in the size of the stats file, and consequently
>> about a 9% increase in the cost of updating it.
> 
> Wups, sorry, I was looking at the wrong struct.  It's actually an
> addition of 1 doubleword to a struct of 21 of 'em, or about 5%.
> That's still an awful lot in comparison to the prospective usefulness
> of the information.
> 
>             regards, tom lane
> 

OK, so here goes the simplified patch - it tracks one reset timestamp
for a background writer and for each database.

regards
Tomas

PS: I've noticed Magnus posted a patch to track recovery conflicts,
adding a new view pg_stat_database_conflicts. I have not checked it yet
but it should not influence this patch.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: wCTE behaviour
Следующее
От: Robert Haas
Дата:
Сообщение: Re: keeping a timestamp of the last stats reset (for a db, table and function)