From: | Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Buglist |
Date: | 2003-08-22 10:57:53 |
Message-ID: | 200308221627.53226.shridhar_daithankar@persistent.co.in |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Friday 22 August 2003 16:23, Manfred Koizar wrote:
> On Fri, 22 Aug 2003 12:15:33 +0530, "Shridhar Daithankar"
>
> <shridhar_daithankar(at)persistent(dot)co(dot)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.
Shridhar
From | Date | Subject | |
---|---|---|---|
Next Message | Thierry Missimilly | 2003-08-22 12:25:25 | Proble when running DBMirror.pl |
Previous Message | Manfred Koizar | 2003-08-22 10:53:29 | Re: Buglist |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-08-22 12:27:13 | Re: postgresql 7.3.2 bug on date '1901-12-13' and '1901-12 |
Previous Message | Manfred Koizar | 2003-08-22 10:53:29 | Re: Buglist |