Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group