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 4D0EA74E.6060701@fuzzy.cz
обсуждение исходный текст
Ответ на 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 23:58, Tom Lane napsal(a):
> Tomas Vondra <tv@fuzzy.cz> writes:
>> > 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.
> If you think this objection is not serious, you're mistaken.

I know there were problems with pgstats.stat and I/O (for example this
thread discussing an I/O storm
http://archives.postgresql.org/pgsql-hackers/2008-01/msg01095.php).

But I thought those issues were already resolved and I have not noticed
any such issue recently. Am I missing something?

> What is bothering me about that is this: how many of our users ever
> reset the stats at all?  Of those, how many reset the stats for just
> some tables and not all of them?  And of those, how many care about
> having the database remember when they did it, at a per-table level?
> I think the answer to each of those questions is "not many", and so
> the fraction of our users who will get a benefit from that added
> overhead is epsilon cubed.  But approximately 100% of our users will
> be paying the overhead.

Sure, I understand that only a fraction of the users will use the patch
I've proposed. That's why I'm saying that the per-database timestamp
would be sufficient (although I'd prefer the per-record timestamp).

regards
Tomas


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

Предыдущее
От: Florian Pflug
Дата:
Сообщение: Re: pg_ctl and port number detection
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: plperlu problem with utf8