学习的过程中，高大上的学，基础的也要会，POSTGRESQL 学习过程中发现不捋一捋基础的知识，让基础更夯实，则楼搭的不踏实稍微一个问题，可能就要翻车。
版本PG 11
1 在数据目录中的目录有什么，作用是什么
1 base 目录是存储整体POSTGRESQL 数据的目录，而base 里面就是以数据
库的OID为名字的目录，目录里面全是这个数据库里面的表及相关文件。
通过上面的oid 对应文件目录BASE 下的目录存储的文件为当前OID 库的数据库文件。
每个堆和索引关系都有一个空闲空间映射(FSM)来跟踪关系中的可用空间。它与主要关系数据一起存储在一个单独的关系fork中，以关系的文件名和一个_fsm后缀命名,_vm后缀命名。
fsm -- free space maps
其中fsm也有一段故事的，在PG 8.3时fsm是存储在share memory 中的，并且他是一个固定的尺寸，当数据库有大量的删除和更新一集回滚的操作时，很可能因为fsm的问题，造成不能在记录正确的free space。
正是因为这个原因，后面的PG 将_fsm 变成了文件，并且其中文件记录了max_fsm_pages 和 max_fsm_relations
其中提供了pg_freespace 函数来对查看对应blk 中可以利用的空余的空间
_vm 则是可见性映射表， visual map 主要的作用为，在我们update, delete, 行后，这一行tuple 并不会马上被清理掉，而是要通过vacuum ，autovacuum 等操作将这些dead tuple 来清理， vm文件的主要作用是显示占用的tuple ，扫描的时候会跳过这些tuple。
细心的同学可能会发现有些表可能并没有 fsm vm 文件
首先并不是表一开始建立就有 FSM 文件和VM文件，而是在第一次对这样表进行vacuum 时才会建立fsm文件。
如果想知道你的表的物理文件的对应，通过pg_class 表来进行查询
select relname, relfilenode,reltablespace from pg_class where relname = 'film';
而针对VM 文件，又是那个程序在进行vacuum 时进行使用他来跳过那些标记活动的tuple， 对于系统的vacuum 有两种方式 1 Lazy VACUUM 2 Full Vacuum 两种方式对比的不同，在于第一种不会将系统空间释放给操作系统，并且对系统的影响会较小，而第二种方式会将释放的空间给操作系统，并且早操作的过程中，会产生一个独占锁，而影响正在运行的系统。
而在数据文件或索引文件大于某个容量的时候，例如默认为1G的情况下，会生成和这个当前文件 relfilenode 一样数字的但后面有数字的文件。
所以有些文字上试图增加单个文件的大小，尽量不产生过多这样的文件。
另外需要提示的是FSM 文件使用的是树形结构来记录，空闲的页块，通过代码来看也是从左到右的查找。
一些SQL 语句,与目录有关或文件有关
1 查看当前的PG的数据目录
SHOW data_directory;
2 查看数据库的OID
select oid, datname from pg_database ;
3 确认某个表的路径
select pg_relation_filepath('film');
4 确认某个表的表空间和表的relfilenode
select relname, relfilenode,reltablespace from pg_class where relname = 'film';
今天大致说了一个数据库表的存储结构，其实里面还有一些东西没有讲出来，后面还会继续深入。
