Larry Rosenman wrote:
> Alvaro Herrera wrote:
> > Alvaro Herrera wrote:
> >> Matthew T. O'Connor wrote:
> >>> Bruce Momjian wrote:
> >>>> Matthew T. O'Connor wrote:
> >>>>
> >>>>> Any chance we can make this change before release? I think it's
> >>>>> very important to be able to look through the logs and *know*
> >>>>> that you tables are getting vacuumed or not.
> >>>>>
> >>>>
> >>>> Agreed. I just IM'ed Alvaro and he says pg_stat_activity should
> >>>> now show exactly what autovacuum is doing (and if it doesn't,
> >>>> let's fix it). I think that is the best solution to the monitoring
> >>>> problem, rather than throwing lines in the server logs.
> >>>
> >>> I'm not sure I agree with this. I can use the pg_stat_activity
> >>> table to see if autovacuum is doing something right now, but what I
> >>> want to be able to do is look through my logs and see that
> >>> table_foo hasn't been vacuumed since last week, or that table_bar
> >>> has been vacuumed 7 times today. Can I do that just with the stat
> >>> system alone?
> >>
> >> Actually Larry just reminded us that you can use pg_stat_all_tables
> >> to see that information. However I'm testing it and it doesn't seem
> >> to work for all tables ... strange. I'll have a look.
> >
> > Nevermind -- it's just that if you vacuum a table which you haven't
> > touched (insert, update, delete) since the last stats reset, then the
> > vacuum info isn't recorded because we refuse to create the pgstat
> > entry for the table.
>
> Do I need to write a Doc patch for that? It seemed consistent with other
> functions of the
> same class when I did the date patch.
I'm not sure. It just makes sense overall ... the fact that the
collector chooses to discard some info should be documented somewhere I
think (maybe it already is, I don't know), but not specifically for the
vacuum times.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support