From: | "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Buglist |
Date: | 2003-08-22 15:00:27 |
Message-ID: | 3F467D63.2240.1E0E46@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On 22 Aug 2003 at 10:45, Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> > Shridhar Daithankar wrote:
> >> 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.
>
> Right. One big question mark in my mind about these "partial vacuum"
> proposals is whether they'd still allow adequate FSM information to be
> maintained. If VACUUM isn't looking at most of the pages, there's no
> very good way to acquire info about where there's free space.
Somehow it needs to get two types of information.
A. If any transaction is accessing a page
B. If a page contains any free space.
Vacuum needs to look for pages not in A but in B. Can storage manager maintain
two lists/hashes with minimal cost? In that case, all unlocked and not in
transaction pages could be a much smaller subset.
Does it sound bizzare?
Bye
Shridhar
--
Chemicals, n.: Noxious substances from which modern foods are made.
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-08-22 15:03:27 | Re: [HACKERS] Buglist |
Previous Message | btober | 2003-08-22 14:54:51 | Re: pg_dump and alter database |
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 2003-08-22 15:03:27 | Re: [HACKERS] Buglist |
Previous Message | Tom Lane | 2003-08-22 14:45:50 | Re: [HACKERS] Buglist |