Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
> I've done several small changes to the patch, namely

> - added docs for the functions (in SGML)
> - added the same thing for background writer

> So I think now it's 'complete' and I'll add it to the commit fest in a
> few minutes.

Please split this into separate patches for database-level and
table-level tracking, because I think it's highly likely that the latter
will get rejected.  We have had multiple complaints already about the
size of the stats file for databases with many tables.  I don't believe
that it's worth bloating the per-table entries even further with this
information.  Tracking reset time it per-database doesn't seem like a
problem though.

			regards, tom lane

In response to

• Re: keeping a timestamp of the last stats reset (for a db, table and function) at 2010-12-19 01:23:09 from Tomas Vondra

Responses

• Re: keeping a timestamp of the last stats reset (for a db, table and function) at 2010-12-19 11:36:20 from tv
• Re: keeping a timestamp of the last stats reset (for a db, table and function) at 2010-12-19 18:13:49 from Jim Nasby

pgsql-hackers by date

Next:	From: Robert Haas	Date: 2010-12-19 03:04:10
	Subject: Re: Extensions, patch v20 (bitrot fixes) (was: Extensions, patch v19 (encoding brainfart fix))
Previous:	From: Tomas Vondra	Date: 2010-12-19 01:23:09
	Subject: Re: keeping a timestamp of the last stats reset (for a db, table and function)