Re: Autovacuum in the backend - Mailing list pgsql-hackers

From Gavin Sherry
Subject Re: Autovacuum in the backend
Date
Msg-id Pine.LNX.4.58.0506171913170.31550@linuxworld.com.au
Whole thread Raw
In response to Re: Autovacuum in the backend  (Russell Smith <mr-russ@pws.com.au>)
List pgsql-hackers
On Fri, 17 Jun 2005, Russell Smith wrote:

> > Added to TODO:
> >
> >  * Create a bitmap of pages that need vacuuming
> >
> >    Instead of sequentially scanning the entire table, have the background
> >    writer or some other process record pages that have expired rows, then
> >    VACUUM can look at just those pages rather than the entire table.  In
> >    the event of a system crash, the bitmap would probably be invalidated.
> >
> Further to this, is there any use case for allowing FSM, or this DSM to spill to disk
> if the space fills up.  It would allow the possibility of unusual changes to the db
> to not loose space.  You could just load part of the overflow from the disk back
> int the FSM in memory and continue using free space.

FSM splilling to disk would be a problem. The reason is that when we need
to allocate an empty page, we hit the FSM first. If that operation becomes
disk bound, large updates and inserts are going to really suck from a
performance point of view.

The idea I discussed is disk backed, because its the first few pages of
every heap segment. This map doesn't mean that pages are free. It means
they've been modified.

Gavin


pgsql-hackers by date:

Previous
From: Russell Smith
Date:
Subject: Re: Autovacuum in the backend
Next
From: Andreas Pflug
Date:
Subject: Re: Utility database (Was: RE: Autovacuum in the backend)