Re: [GENERAL] Buglist - Mailing list pgsql-hackers

From Jan Wieck
Subject Re: [GENERAL] Buglist
Date
Msg-id 3F462A63.8090906@Yahoo.com
Whole thread Raw
In response to Re: [GENERAL] Buglist  (Shridhar Daithankar <shridhar_daithankar@persistent.co.in>)
Responses Re: [GENERAL] Buglist  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Shridhar Daithankar wrote:

> On Friday 22 August 2003 16:23, Manfred Koizar wrote:
>> On Fri, 22 Aug 2003 12:15:33 +0530, "Shridhar Daithankar"
>>
>> <shridhar_daithankar@persistent.co.in> 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.                                  #
#================================================== JanWieck@Yahoo.com #


pgsql-hackers by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: [GENERAL] Buglist
Next
From: Tom Lane
Date:
Subject: Re: [GENERAL] Buglist