postgresql.conf中的这个参数（max_fsm_pages）用于告诉 Postgresql申请多大的内存空间用于保存数据文件的free space信息，按我的简单理解，如果在一个表中删除了一些记录，Postgresql会把这一改动记录在"Free Space Map"中，下次如果再往表里插记录时，根据Free Space Map中的信息，就能利用以前删记录而腾出来的磁盘空间。 不过Free Space Map是存在于内存中，大小毕竟是有限的，对于大量数据的删除＋插入，要么指定一个较大的max_fsm_pages,要么及时进行vacuum以整理表中的碎片，否则，Postgresql只有把新插入的记录添加到文件的末尾，造成文件越来越大。 我的一个程序就是意外地因为磁盘空间满了而中止的，它每次要往一个表里插500多万条记录，这之前先要delete同样条数的一批记录，可最后还是占满了整个硬盘。 我觉得Postgresql的这种工作方式有它的一个好处，就是如果内存足够大，可以指定一个很大的Free Space Map，对于OLTP 型的应用，可能会大幅提高性能（猜测，没有验证过），另外用户可以自已选择在合适的时候进行vacuum或vacuum full，如果你确信一个表只会往里插记录（如记录操作日志），对这个表就可以永远不进行vacuum full，是不是很灵活？ 不过，使用vacuum full大量移动数据毕竟是件很耗时的工作，在此期间数据库性能会严重下降，大概这就是“灵活”的代价了。在这方面，Oracle的Block->;Extent->;Segment这种复杂的机制可能更有效一些吧。 据说Postgresql将引入表空间的概念了，值得期待啊！ 至于Free Space Map设多大，上面的文章教了个办法，照着做就行了，只是需要弄明白，这毕竟是一个“Map”，如果打算删掉300M的记录，Free Space Map并不需要申请300M喔 。