在PG中, 凡是要对存储在磁盘中的表进行磁盘操作(如打开/关闭,读/写等),
都是必须与磁盘管理器打交道, 由它来统一处理.
3.2.4 空闲空间映射表
随着表中不断插入和删除元组, 文件块中必然会产生空闲空间(freee space).
在插入元组时优先选择将其存放在空闲空间内是利用存储的好方法.
但是这需要在该表众多拥有空闲空间的文件块之间进行选择,
而遍历所有文件块进行选择的开销将是非常庞大的.在PG8.4之前使用了一种全局FSM文件来记录所有表文件的空闲空间状况,
其缺点是在全局FSM文件中只能记录每个表文件一定数量的文件块空闲空间状况.这使得对于空闲空间的管理比较复杂和低效.为了解决这一问题,
PG8.4中采用了一种新的策略,即对于每个表文件(包括系统表在内),
同时创建一个名为”关系表OID_fsm”的文件,
用于记录该表的空闲空间大小,称之为空闲空间映射表文件(FSM).
例如, 一个OID为12000的表, 其空闲空间映射表文件将被命名为12000_fsm.
3.2.5 可见性映射表PG中为了实现多版本并发控制, 录事务删除或更新元组时, 并非从物理上删除,
而是通过将其标记为无效的方式进行标记删除,
最终对这些无效元组的清理操作需要调用VACUMM来完成.
在PG中提供了两种大数据存储方式:第一种是TOAST机制, 使用数据压缩和线外存储来实现;
第二种是大对象机制, 使用一个专门的系统来存储大对象数据.
不管是什么样的数据库管理系统, 其存储管理中涉及的问题本质是一样的:
如何减少I/O次数.
在磁盘上读或写一个块大约要花10~30毫秒,在这段时间内一台普通的机器或许能执行数万条指令.在通常情况下,读写磁盘所用的时间决定了数据库操作所花费的总时间.
因此, 要尽可能地站最近使用的文件块停留在内存中,这样就能有效地减小磁盘I/O的代价.
合理有效的内存管理对于整个DBMS的性能起着非常重要的作用.
PG的内存管理包括哪2个方面PG中的内存管理包括对共享内存和本地内存的管理.
在PG的旧版本中, 常常需要处理大量以指针传值的查询,
因而存在着内存泄漏的问题,直到查询结束才能将内存收回.
尤其是在处理引用TOAST机制的查询时, 需要使用大量的内存, 使得这个问题尤为明显.
为此, 从版本7.1开始, PG中实现了新的内存管理机制---内存上下文(MemoryContext).
系统中的内存分配操作在各自语义的内存上下文中进行,所有在内存上下文分配的内存空间都通过内存上下文进行记录.
因此可以很轻松地通过释放内存上下文来释放其中的所有内容,而不用费心地释放其中的每一块内存,
使得内存分配和释放更加快捷和可靠,
内存上下文机制借鉴了操作系统的一些概念. 我们知道,
操作竹编为每个进程分配了进程执行环境, 进程环境之间不互相影响,
由操作系统来对环境进行切换,进程可以在其进程环境中调用一些库函数(如malloc, free,
realloc等)来执行内存操作.
类似的, 一个内存上下文实际上就相当于一个进程环境,
PG以类似的方式提供了在内存上下文进行内存操作的函数: palloc, pfree, repalloc等.
5部分:
MemoryContext
内存上下文初始化与创建
内存上下文中内存的分配
内存上下文中内存重分配
释放内存上下文
3.3.2 高速缓存当数据库访问表时, 需要表的模式信息, 比如表的列属性,OID,统计信息等.
PG将表的模式信息存放在系统表中,因此要访问表,就需要首先在系统表中取得表的模式信息.对于一个PG系统来说,
对于系统表的普通表模式的访问是非常频繁的. 为了提高这些访问的效率,
PG设立了高速缓存(Cache)来提高访问效率.
当数据库访问表时,需要表的模式信息,比如表的列属性,OID,统计信息等.PG将表的模式信息放在系统表中,因此访问表,就需要首先在系统表中取得表的模式信息.
对于一个PG系统来说,对于系统表和普通表模式的访问是非常频繁的.
为了提高这些访问的效率,PG设立了高速缓存(Cache)来提高访问效率.
高速缓存包括几个部分高速缓存Cache中包括一个系统表元组Cache(SysCache)和一个表模式信息Cache(RelCache).
SysCache中存放的是最近使用过的系统表的元组,而RelCache中包含所有最近访问过的表的模式信息(包含系统表的信息).