数据源的港湾

在这个特殊的例子中，我们取两个最低的位，得到0到3的值;通过绝对统一的数据分布和没有散列冲突，您可以使用更高的填充因子值，但在实际数据库中，它会增加页面溢出的风险。由于哈希函数将返回一个相同的值，因此所有数据将被放置到相同的桶中，并且增加桶的数量不会有帮助。为了在一定程度上平衡这种增长并避免一次分配过多的页面，从第10次增加开始，将页面分配为四个相等的批次，而不是一次分配所有的页面。综合所有页面的统计数据，桶0是空的，而所有的值都被放到了桶1中:其中一些位于主页面，不适合的可以在溢出页中找到。

合并连接处理的数据集，并返回以类似方式排序的结果。输入集可以在索引扫描后预先排序;否则，执行者必须在实际合并开始之前对它们进行排序。

在这种情况下，节点被分成两个，旧节点的一些元素被移动到新节点中，指向新子节点的指针被添加到父节点中。此外，可能有太多的副本，以至于它们不适合单个节点，因此相邻的叶节点也必须处理。如果搜索是通过条件“索引-列 ⩽expression”(或“索引-列⩾expression”)执行的，我们必须首先搜索满足相等条件的值的索引，然后在所需的方向遍历其叶节点，直到到达树的末端。您可以注意到，树的内部节点中最左边的键是冗余的:要选择根的子节点，只要满足条件KJA < OVB就足够了。生成的新节点在下面的图中突出显示。

因此，在最坏的情况下，walwriter需要运行三次才能到达特定的WAL条目:首先，它将写入位于缓存末尾的所有完整页面，然后它将返回到开头，最后，它将处理包含条目的未填充页面。由于这种类型的加载与典型的数据文件访问非常不同，因此有必要为WAL文件设置一个单独的物理存储，并用一个指向已挂载文件系统中的目录的符号链接替换PGDATA/pg_wal编录。当然，每个特定系统都有自己的数据，具体取决于当前负载，但很明显，对短OLTP事务的影响是非常明显的。从暂停中唤醒，进程检查缓存中是否有新的完全填满的WAL页面。

由于检查点在启动时不记录任何日志，因此该LSN可以属于任何类型的WAL条目。

因此，如果外部集的mcv上有常规的非多元统计信息(即，外部集由表表示，连接由单列执行)，则具有与mcv对应的哈希码的行被认为是第一批的一部分。例如，如果键列在其所有行中包含一个相同的值，则它们将被放入同一个批处理中，因为散列函数将一次又一次地返回相同的值。两遍连接的启动成本是基于单遍连接的启动成本，这是由于写入尽可能多的页面以存储内部集所有行的所有必要字段的估计成本而增加的。每个批处理实际上被分成两个新的批处理:大约一半的行(假设分布是均匀的)留在哈希表中，而另一半保存到一个新的临时文件中。

这里，Nested Loop节点遍历外层集合(tickets)的行，并对每一行搜索内部集合(ticket_flights)的对应行，将机票号(t.t ticket_no)作为参数传递给条件。可以更准确地估计列表中出现的行的选择性，只有剩下的行必须依赖基于均匀分布的计算。如果对Memoize节点的调用显示传递的参数值与已经缓存的行对应，则这些行将被传递到父节点(Nested Loop)，而不检查子节点。由于连接的表是通过外键连接的，因此选择性估计依赖于子表的每一行在父表中恰好有一个匹配行的事实。

Oracle在修改数据前会把数据的旧值先写到undo表空间中以实现MVCC，而PG中的更新操作会被转换为delete+insert操作，然而这个delete并不是真正的把数据立刻删除掉，而是通过修改记录中的隐藏列来标记此行被删除，并在之后的某个时间通过后台任务来进行无效数据的清理。怎么理解呢，其实这些是相对Oracle的MVCC来说的，正如前面说的，Oracle的MVCC实现是把修改前数据存放在独立的undo表空间中，那么它就存在几个不足之处。当然了，PG的MVCC机制有好处，但它也是有坏处的。

特别是在关联时对于三大JOIN技术：hash join、merge join、nestloop join的支持，MySQL只支持最后一种nestloop join（未来会支持hash join），而多个大表关联分析时hash join是必备的利器，缺少这些关联功能非常致命，难以在OLAP领域充当大任。PG中contrib目录下的各个第三方模块，在GP中的postgis空间数据库、R、MADLIB、pycrypto各类加密算法、gptext全文检索都是通过这种方式实现扩展的。的，没有被大公司控制，

本文描述YMatrix 5.1版本的安装过程，由于使用的操作系统为CentOS 7，具体步骤参考官网。

注：本文翻译自Oracle关系数据库管理系统(RDBMS)已被大型组织广泛使用，被认为是迄今为止市场上最先进的数据库技术。通常将RDBMS与作为产品应该提供的标准“事实”的其他数据库产品进行比较。它被db- enginees.com评为当今市场上可用的头号RDBMS。PostgreSQL被列为排名第四的RDBMS，但这并不意味着迁移到PostgreSQL没有任何优势。PostgreSQL自1989年以来一直存在，1996年开源。

注：本文引用自。

在Uber的早期，Postgres为我们提供了很好的服务，但随着我们的增长，我们在扩展Postgres方面遇到了重大问题。今天，我们有一些遗留的Postgres实例，但我们的大部分数据库要么构建在MySQL之上(通常使用我们的Schemaless层)，要么在某些特殊情况下，构建在Cassandra这样的NoSQL数据库之上。总的来说，我们对MySQL非常满意，将来我们可能会有更多的博客文章来解释它在Uber的一些更高级的用法。

在前面我们了解了PG数据库的故障恢复依赖于在启动时通过回放WAL段文件中的XLOG记录来完成，这篇我们学习一下PG数据库中WAL段文件是怎么管理的。首先，我们需要知道WAL段文件是保存在pxg_xlog（PG V10版本以前，在PG V10版本以后变成 pg_wal）子目录下，如果一个WAL段文件写满后就会切换到一个新的段文件。总的WAL段文件个数由几个配置参数决定的。此外，对于WAL段文件的管理机制在PG 9.5版本得到了提升。

前面我们了解到PostgreSQL的故障恢复与checkpoint、WAL密切有关。当数据库异常宕机，通过顺序的重放WAL段文件中从重做点（REDO point）开始的XLOG记录来进行数据库的恢复操作。

在文章中我们学习了PG数据库中有好几个background后台进程，其中一个后台进程是checkpointer检查点进程。这里我们学习一下什么是checkpointer检查点进程以及它的用处。当然，由超级用户手工触发CHECKPOINT命令也可以调度checkpoint工作。下面再了解一下checkpoint过程都包含哪些内容。

PostgreSQL数据库把事务的状态信息保存在Commit Log（简称clog）中，clog被分配在共享内存shared memory，记录事务的所有状态变化。下面我们先了解一下事务状态都有哪些。

PostgreSQL作为一个单机的关系型数据库，与单机Oracle的架构是比较相似的，与MySQL的InnoDB引擎也比较像。据我目前的了解，单机数据库的整体架构都差不太多，都是包含一个主的进程，一些辅助进程，以及一个大的共享内存池。下面我们具体学习一下PG架构里面的这些部分。

前面我们介绍了PG中的Concurrent VACUUM，详细请参考，这篇我们继续来了解一下PG中的Full VACUUM。我们了解Concurrent VACUUM允许在执行的时候仍然允许对正在VACUUM的表进行读取操作，因此这个操作对业务的影响也比较小。但是Full VACUUM在执行期间是不允许对相关表进行任何操作的，所以它对业务的影响也比较大，那么为什么还需要Full VACUUM呢？我们假如以下一种场景，一个表有三个Page，每个Page里面有6条Tuple，如下图所示。

在前面一文中我们初步了解到PG中是采用了MVCC多版本机制，数据在删除时并不会直接从页面中删除掉而是通过修改t_xmax将其标记为delete，更新数据也是通过把原数据标记为delete并插入一条新记录的形式。既然老的数据不会立马删除，那数据库一定就得一些其他的机制可以进行异步的清理，否则数据库长久肯定会有数据膨胀的问题存在。PG中为了清理老的无用数据，引入了VACUMM机制。。

在上一篇文章中我们了解了PostgreSQL中堆表的存储结构，以及对于堆表的tuple是如何写入和读取的，不过我们只涉及到如何把想要的tuple从表对应的页面读取出来或者把tuple如何写到页面去，但是关于tuple内部的细节并没有说明。本文我们将着重学习一下tuple的内部结构以及对于增删改操作tuple是如何变化的。

SQL Server关于堆表的描述如下，没有聚集索引的表堆表在sys.partitions里有1条index_id = 0 的记录数据存储没有任何的顺序，插入数据也没顺序由于数据没有任何顺序，查询数据会非常慢数据页之间没有相互链接从数据页读取数据，需要从IAM（Index Allocation Map）页里找页号。