Simon Riggs wrote:
On Thu, 2007-11-08 at 21:50 -0300, 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.
I was trying to guess at Heikki's reason for saying the FSM should be in
a separate file. If we have one extra file per table that seems like a
huge number of additional files, with space and fsync implications.
You need the same amount of space either way. Well, I guess additional
files consume some space in the filesystem directory structures. I doubt
that matters.
You do need more fsyncs, and more overhead when creating/dropping
relations, to create/unlink the FSM files. I don't know how significant
that is.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
