Re: Autovacuum and OldestXmin - Mailing list pgsql-hackers

From Christopher Browne
Subject Re: Autovacuum and OldestXmin
Date
Msg-id 87hcjd6518.fsf@wolfe.cbbrowne.com
Whole thread Raw
In response to Autovacuum and OldestXmin  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Autovacuum and OldestXmin  (Simon Riggs <simon@2ndquadrant.com>)
Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Replacement Selection  (<mac_man2005@hotmail.it>)
Re: Autovacuum and OldestXmin  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
The world rejoiced as alvherre@alvh.no-ip.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. 


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [GENERAL] possible to create multivalued index from xpath() results in 8.3?
Next
From: Euler Taveira de Oliveira
Date:
Subject: Re: wrong behavior using to_char() again