"Simon Riggs" <simon@2ndquadrant.com> writes:
> 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.
I don't follow any of the logical leaps in this paragraph.
[We talked about this...]
Why would having the FSM info be physically addressed into every nth page of
the heap allow FSM blocks to be more easily found than having them be
physically addressed in a separate file? Why would separate files mean more
space or more fsyncs?
> 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.
That's one of the advantages of using separate files. It would be easy to have
or not have a whole file. It would be pretty hard to know whether the bits
spread on every nth page are missing and hard to add them later if the table
grows and they're needed.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!
