"Simon Riggs" <[EMAIL PROTECTED]> 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! ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate