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

Re: Autovacuum and OldestXmin

From: Christopher Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Autovacuum and OldestXmin
Date: 2007-11-23 02:59:15
Message-ID: 87hcjd6518.fsf@wolfe.cbbrowne.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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 ;-).

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.

If there is some elderly, long-running transaction that isn't a
VACUUM, that will indeed inhibit VACUUM from doing any good, globally,
across the cluster, until such time as that transaction ends.

To, at that point, "inhibit" autovac from bothering to run VACUUM,
would seem like a good move.  There is still value to running ANALYZE
on tables, so it doesn't warrant stopping autovac altogether, but this
scenario suggests a case for suppressing futile vacuuming, at least...
-- 
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://linuxfinances.info/info/slony.html
It's hard to tell if someone is inconspicuous. 

In response to

Responses

pgsql-hackers by date

Next:From: Euler Taveira de OliveiraDate: 2007-11-23 03:54:03
Subject: Re: [HACKERS] wrong behavior using to_char() again
Previous:From: Peter EisentrautDate: 2007-11-22 22:56:38
Subject: Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?

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