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

Re: BUG #5722: vacuum full does not update last_vacuum statistics

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jochen Erwied <jochen(at)pgsql(dot)erwied(dot)eu>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5722: vacuum full does not update last_vacuum statistics
Date: 2011-02-27 23:04:52
Message-ID: 201102272304.p1RN4qb17352@momjian.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Tom Lane wrote:
> Jochen Erwied <jochen(at)pgsql(dot)erwied(dot)eu> writes:
> > Monday, October 25, 2010, 4:12:39 PM you wrote:
> >> "Jochen Erwied" <jochen(at)pgsql(dot)erwied(dot)eu> writes:
> >>> VACUUM FULL does not update statistics so display of pg_stat_user_tables is
> >>> wrong. A normal VACUUM updates the relevant information.
> 
> >> Hmm.  This is a definitional issue: what do we really mean by last_vacuum?
> >> I'm inclined to think that the current behavior is reasonable.  VACUUM
> >> FULL is (still) not intended as a routine maintenance operation, and
> >> the point of that column is to track routine maintenance operations.
> 
> > Well, when reading 
> > http://www.postgresql.org/docs/current/static/monitoring-stats.html 
> > then last_vacuum contains the last time of a user-initiated vacuum. There's 
> > no distinction made what kind of vacuum was made. And IMHO even if VACUUM 
> > FULL isn't meant for routine vacuuming, the state should be changed.
> 
> Perhaps.  The new implementation of VACUUM FULL is really more like a
> CLUSTER, or one of the rewriting variants of ALTER TABLE.  Should all
> of those operations result in an update of last_vacuum?  From an
> implementation standpoint it's difficult to say that only some of them
> should, because all of them result in a table that has no immediate
> need for vacuuming.  The only argument I can see for having only VACUUM
> FULL update the timestamp is that it's called VACUUM and the others
> aren't.  Which is an argument, but not a terribly impressive one IMO.
> 
> > Of course the easiest way to fix this bug (or better flaw) is to change the
> > documentation :-)
> 
> Yeah, that part of the docs will require editing no matter what we do.
> I'm just trying to get some clarity on what the most reasonable behavior
> is.

I have updated the documentation to say that vacuum statistics and
counts are for non-FULL vacuums;  applied patch attached.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

Attachment: /rtmp/vacuum.diff
Description: text/x-diff (2.0 KB)

In response to

pgsql-bugs by date

Next:From: Gie RizkiadiDate: 2011-02-28 03:13:28
Subject: BUG #5901: Delayed Write Failed
Previous:From: Bruce MomjianDate: 2011-02-26 07:14:37
Subject: Re: BUG #5707: Cross compilation for windows is broken

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