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

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've never had problems with the pgstat.dat file, but I understand
> others might, although this adds "just 8 bytes" to each item.

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.

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.

That just doesn't look like a good tradeoff from here.

regards, tom lane