On Thu, 2007-11-08 at 15:24 +0000, Heikki Linnakangas wrote: > I still feel the FSM should be in a file of it's own, rather than > distributed on every nth heap page. It makes scanning it quicker, > because it's sequential rather than random access, we're going to need > a > solution for indexes as well, and using the special area of heap > pages > would make the locking quite tricky.
I'd like to see the analysis on each side of that decision, so we can decide openly. The pages might well be in cache, so the file location might well be irrelevant from an I/O perspective. Maybe. The nth page solution allows the FSM block to be easily located without any FSM index, so might well be faster. Separate files mean more space and more fsyncs too. But even so, I'm not sure either way. 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. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.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
