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

Tomas Vondra wrote:
> OK, so here goes the simplified patch - it tracks one reset timestamp
> for a background writer and for each database.
>

Adding timestamps like this was something I wanted to do after adding
pg_stat_reset_shared to 9.0, so since you've beaten me to it I'll review
your patch and make sure it all works the way I was hoping instead. The
whole per-table idea was never going to fly given how few people touch
this area at all, but the way you're tracking things now seems reasonable.

When you post an updated version of a patch that's already being tracked
on the CommitFest app, please try to remember to add that update to the
tracker there. I just did that for this 12/23 update so that's covered
already.

Next problem is that the preferred method for submitted patches uses
context diffs. See http://wiki.postgresql.org/wiki/Working_with_Git for
some information about the somewhat annoying way you have to setup git
to generate those. Don't worry about that for this round though. I
don't care about the diff formatting given the code involved, but it's
something you should sort out if you do another update.

> PS: I've noticed Magnus posted a patch to track recovery conflicts,
> adding a new view pg_stat_database_conflicts. I have not checked it yet
> but it should not influence this patch.
>

I need to do some testing of that anyway, so I'll take a look at any
potential clash as part of my review. I want to check how this
interacts with track_functions resets too.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books