Re: keeping a timestamp of the last stats reset (for a db, table and function)

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: keeping a timestamp of the last stats reset (for a db, table and function)
Date: 2010-12-20 00:46:06
Message-ID: 4D0EA74E.6060701@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dne 19.12.2010 23:58, Tom Lane napsal(a):
> Tomas Vondra <tv(at)fuzzy(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2010-12-20 00:56:55 Re: plperlu problem with utf8
Previous Message Florian Pflug 2010-12-20 00:04:48 Re: pg_ctl and port number detection