Re: Autovacuum and OldestXmin - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Autovacuum and OldestXmin
Date
Msg-id 20071122182006.GJ4903@alvh.no-ip.org
Whole thread Raw
In response to Autovacuum and OldestXmin  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Autovacuum and OldestXmin  (Tom Lane <tgl@sss.pgh.pa.us>)
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  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
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.


> Why isn't VACUUM optimised the same way HOT is?
> Why doesn't VACUUM continue onto the next block when !PageIsPrunable().
> Nothing is documented though it seems "obvious" that it should.
> 
> Perhaps an integration oversight?

Yeah.

> [Also there is a comment saying "this is a bug" in autovacuum.c
> Are we thinking to go production with that phrase in the code?]

Yeah, well, it's only a comment ;-)  The problem is that a worker can
decide that a table needs to be vacuumed, if another worker has finished
vacuuming it in the last 500 ms.  I proposed a mechanism to close the
hole but it was too much of a hassle.

Maybe we could remove the comment for the final release? :-)

-- 
Alvaro Herrera       Valdivia, Chile   ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Management by consensus: I have decided; you concede.
(Leonard Liu)


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Autovacuum and OldestXmin
Next
From: Tom Lane
Date:
Subject: Re: Autovacuum and OldestXmin