Just a small thought. If the file decision is preferred, then it might
be worth considering to create a file per tablespace.
Thanks,
Gokul.
On Nov 9, 2007 7:15 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
>
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>
