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

Re: Autovacuum and OldestXmin

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Christopher Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Autovacuum and OldestXmin
Date: 2007-11-26 10:58:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, 2007-11-22 at 21:59 -0500, Christopher Browne wrote:
> The world rejoiced as alvherre(at)alvh(dot)no-ip(dot)org (Alvaro Herrera) wrote:
> > Simon Riggs wrote:
> >> I notice that slony records the oldestxmin that was running when it last
> >> ran a VACUUM on its tables. This allows slony to avoid running a VACUUM
> >> when it would be clearly pointless to do so.
> >> 
> >> AFAICS autovacuum does not do this, or did I miss that?
> >
> > Hmm, I think it's just because nobody suggested it and I didn't came up
> > with the idea.
> >
> > Whether it's a useful thing to do is a different matter.  Why store it
> > per table and not more widely?  Perhaps per database would be just as
> > useful; and maybe it would allow us to skip running autovac workers
> > when there is no point in doing so.
> I think I need to take blame for that feature in Slony-I ;-).

Good thinking.

> I imagine it might be useful to add it to autovac, too.  I thought it
> was pretty neat that this could be successfully handled by comparison
> with a single value (e.g. - eldest xmin), and I expect that using a
> single quasi-global value should be good enough for autovac.

I've just looked at that to see if it is that easy; I don't think it is.

That works for slony currently because we vacuum all of the slony tables
at once. Autovacuum does individual tables so we'd need to store the
individual values otherwise we might skip doing a VACUUM when it could
have done some useful work.

  Simon Riggs

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2007-11-26 10:59:26
Subject: Re: 8.3devel slower than 8.2 under read-only load
Previous:From: Marko KreenDate: 2007-11-26 10:25:53
Subject: Re: plpgsql: another new reserved word

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