On Fri, 2007-11-09 at 09:23 +0000, Heikki Linnakangas wrote:
> Alvaro Herrera wrote:
> > Simon Riggs wrote:
> >> Presumably we would not store an FSM for small tables? On the basis that
> >> the purpose of the FSM is to save on pointless I/O there must be a size
> >> of table below which an FSM is just overhead.
> >
> > Hmm, do you mean that we would open and verify every page of a small
> > relation until we find one with free space? That doesn't sound very
> > good.
>
> There is a threshold somewhere. If the heap consists of just one page,
> clearly the FSM doesn't give any benefit. If it's two pages, it's
> probably still faster to just check the two pages. Somewhere after that
> the FSM starts to pay off.
I think that might be set higher than two blocks. Smaller tables tend to
have lower insert rates. If we don't have an FSM for a table we can then
just pick a random block and then seqscan to locate a block. That would
allow heavily hit small tables to avoid much of the contention.
> Whether the overhead is big enough that we care to optimize by not
> having the FSM for tiny tables, I don't know. Probably not. If the FSM
> is stored in the heap file, it's tricky to add the FSM after the fact.
Could we make a specific block number the FSM block. Say block 13, plus
other periodically throughout the table, according to how many data
blocks an FSM block serves? That way a table smaller than that doesn't
have an FSM block, plus we can just insert the FSM block naturally as
part of the insert process without filesystem operations, catalog
changes etc.. SeqScans can just step over that block.
Binary upgrades would be somewhat harder, but not that much.
If we have a separate file for each FSM then we are going to use up
considerably more shared memory for the FSM than we do now, since each
block would be 8k. Plus all the filesystem ops.
Anyway, I'm just asking for an analysis either way. I wouldn't call the
FSM-in-the-heap idea truly wonderful and it definitely isn't my idea, so
not wedded to it.
-- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com
