Re: Free Space Map thoughts - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Free Space Map thoughts
Date
Msg-id 1194615952.4251.452.camel@ebony.site
Whole thread Raw
In response to Re: Free Space Map thoughts  (Heikki Linnakangas <heikki@enterprisedb.com>)
Responses Re: Free Space Map thoughts  ("Gokulakannan Somasundaram" <gokul007@gmail.com>)
List pgsql-hackers
On Fri, 2007-11-09 at 13:27 +0000, Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > One idea is to have the first FSM page be movable, and create it by
> > extending the table when as soon as it's first "needed" (this would be
> > the first vacuum that needs to record free space on the table).  The
> > page number used is recorded in the relcache entry (and pg_class).
> > Further FSM pages use a fixed position.  If the table grows beyond the
> > first fixed position before creating the first FSM page, reserve that
> > one for the first FSM page and record that.
> 
> It wouldn't need to be movable. We could just allocate the first FSM 
> page when the table grows bigger than say 10 pages. The first FSM page 
> would always be at block 11, and it could store the free space 
> information for pages 0-10 as well.
> 
> I'm not particularly worried about the bloat on small tables, though. If 
> a table that used to take 8k bytes now takes 16k, who cares. You 
> wouldn't need to load the FSM pages to shared buffers unless the FSM is 
> actually used.

I'm more worried about the shared memory space we would waste if we have
FSM blocks for very small tables.

Now we use very few bytes per block, which is memory efficient for lots
of small tables and bad with lots of large tables. Putting the FSM in
blocks might change that the other way around. 

--  Simon Riggs 2ndQuadrant  http://www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: New tzdata available
Next
From: Andrew Dunstan
Date:
Subject: Re: New tzdata available