On Friday 22 August 2003 16:23, Manfred Koizar wrote:On Fri, 22 Aug 2003 12:15:33 +0530, "Shridhar Daithankar"
<[EMAIL PROTECTED]> wrote: >> Which leads us to a zero gravity vacuum, that does the lazy vacuum for >> pages currently available in the buffer cache only. [...] > >Since autovacuum issues vacuum analyze only, is it acceptable to say that > this is taken care of already?
Even a plain VACUUM (without FULL) scans the whole relation to find the (possibly few) pages that need to be changed. We are trying to find a way to avoid those needless reads of clean pages, because (a) they are IOs competing with other disk operations and (b) they push useful pages out of OS cache and (c) of PG shared buffers. The latter might become a non-issue with LRU-k, 2Q or ARC. But (a) and (b) remain.
Umm.. What does FSM does then? I was under impression that FSM stores page pointers and vacuum work on FSM information only. In that case, it wouldn't have to waste time to find out which pages to clean.
It's the other way around! VACUUM scan's the tables to find and reclaim free space and remembers that free space in the FSM. The regular backends that need storage space to insert tuples then use the free space in the pages that are recorded in the FSM instead of adding new pages at the end of the relations.
Jan
Shridhar
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
